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To  illustrate  this,  consider  the  assertion  of  a  tuple  in 
the  Request  relation.  Such  a  tuple  nay  be  <a,  r>,  where  the 
object  a  is  a  relation  representing  the  agent,  and  the 
object  r  indicates  the  resource  desired.  This  assertion  was 
made  to  trigger  the  following  rule: 

if  *Request(a,  r) ,  *Avail  (r,  id}  -> 
a  (id)  . 

In  this  example,  the  relation  a  is  used  as  a  mailbox  to 
receive  a  response  from  the  server  rule.  The  assertion  of 
the  tuple  <a,  r>  is  similar  to  the  creation  of  a  conven¬ 
tional  activation  record,  and  the  mailbox  a  is  similar  to 
the  activation  record  of  the  caller. 

The  assertion  a  (id)  places  the  desired  response  —  a 
resource  identifier — in  the  relation  belonging  to  the 
requesting  agent.  When  this  response  appears  in  the  mailbox 
relation,  the  requesting  agent  may  extract  the  result  and 
continue  its  computations.  The  mailbox  relation  serves  as  a 
synchronization  and  value-returning  mechanism. 

In  an  event-driven  system,  such  a  calling  sequence  would 
be  a  common  usage  pattern.  This  is  recognized  by  the  inclu¬ 
sion  of  a  calling  mechanism  within  the  language.  The  above 
sequence  could  be  initiated  by  a  synchronous  call.  Consider 
the  following  rule: 

if  *InitProc  (p)  ,  *Require{j,  r)  ,  -.Allocate  (p,  x)  -> 
Allocate(p,  Request{r}). 

The  Request  expression  in  this  example  is  a  synchronous 
procedure  call.  Its  effect  is  the  automation  of  the  mailbox 
handling  of  the  previous  rule.  The  call  Request  (r;  will  be 
translated  by  the  system  into  an  assertion  Request  (a,  r)  . 
The  object  a  is  a  system-supplied  relation  that  will  receive 
a  response  from  rules  firing  as  a  result  of  the  assertion. 
When  a  tuple  is  added  to  this  relation,  the  tuple  is 
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Named  functions  may  also  be  used  within  expressions  in 
the  same  way  as  the  infix  operators.  This  is  shown  in  the 
following  rule: 

if  *Av  ailTapeDrives  {LI )  ,  *  TapeQueue  (L2)  , 

(11  -*=  Nil)  5  (12  -.=  Nil)  -> 

AvailTapeDrives  (Rest[  11  J)  , 

TapeQueue  (Sest[  12  ])  , 

Allocate (First[ LI ],  First[12]). 

In  this  example,  available  tape  drives  and  jobs  queued  for 
tape  drives  are  represented  as  lists.  The  functions 
First[x]  and  Rest[  x  ]  return  the  head  and  tail  pointers  of 
their  argument. 

Functions  are  declared  as  fellows: 

fn  fact£x]  :  if  x  <=  1  ->  1 

else  x  *  fact[x-1  ]. 

This  example  illustrates  that  function  bodies  are  similar  to 
rules,  and  are  in  fact  conditional  expressions.  The  antece¬ 
dent  of  a  conditional  expression  is  a  Boolean  expression, 
but  not  an  inquiry  or  absence  test.  The  consequent  of  a 
conditional  expression  is  another  expression,  not  an  asser¬ 
tion  or  deletion.  Thus,  conditional  expressions  (and  func¬ 
tion  bodies  derived  from  them)  are  free  of  side  effects.  As 
the  factorial  example  illustrates,  functions  may  be  declared 
recursively.  Iterative  constructs  are  not  defined. 

F.  PROCEDURES 

A  typical  invocation  sequence  for  a  rule  begins  when  a 
tuple  is  added  to  a  relation.  The  tuple  is  associated  with 
an  agent — the  object  or  process  that  made  the  assertion — and 
the  agent  often  expects  a  group  of  rules  to  execute  as  a 
result  of  this  assertion.  Finally,  the  agent  may  expect  a 
value  or  object  to  be  returned. 
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The  cancel  operation  returns  true  if  the  indicated  pattern 
is  matched  against  a  tuple  in  a  relation.  If  the  antecedent 
of  the  rule  succeeds  (all  conditions  are  true)  ,  then  the 
tuples  matched  during  cancel  operations  are  deleted  from 
their  relations. 

Rules  may  be  coupled  through  alternation.  In  the 
preceding  rule,  an  alternate  action  may  be  desired  if  the 
reguested  resource  is  not  available.  This  is  expressed  as: 

if  *Reguest (resource,  job),  *Avail (resource)  -> 

Allocate  (resource,  jot) 
else  if  *Eegues  t  (resource,  job)  -> 

Block ed (resource,  job). 

The  antecedent  of  the  alternate  rule  will  be  evaluated  if 
the  primary  rule  fails.  In  this  example,  the  effect  will  be 
to  place  the  job  in  a  blocked  state. 

E.  THE  APPLICATIVE  COMPONENT 

Function  application  is  used  to  support  the  state  tran¬ 
sitions  described  above.  In  those  cases  where  a  tuple  must 
be  specified,  an  applicative  expression  may  be  used  to 
compute  the  value  of  a  member.  Consider  the  following  rule: 

if  *TapeDrives ( j,  n) ,  n  +  1  <=  10  -> 

TapeDrives  (j,  2  *  n)  . 

This  rule  uses  infix  arithmetic  operators  to  compute  values 
in  a  constraint  and  during  an  assertion.  Such  operators  are 
permissible  in  constraint  expressions  and  in  the  consequent 
portions  of  the  rule,  with  the  restriction  that  variables 
participating  in  such  expressions  must  be  bound.  In  the 
preceding  example,  the  variable  n  was  bound  in  the 
TapeDrives  inquiry. 


If  the  contents  of  the  Bequest  and  Avail  relations  match  the 
inquiry  patterns,  the  rule  will  "fire",  and  add  the  tuple 
<resource,  job>  to  the  Allocate  relation. 

In  the  previous  example,  the  free  variables  resource  and 
job  were  bound  in  the  antecedent  portion  of  the  rule.  These 
bindings  were  maintained  through  the  consequent  portion  of 
the  rule  and  determined  the  instantiation  of  objects  added 
to  the  Allocate  relation.  Free  variables,  therefore,  must 
be  bound  through  pattern-matching  before  their  use  in  the 
consequent  of  a  rule. 

The  allocation  example  raises  some  problems.  The  rule 
successfully  allocates  a  resource  to  a  job  by  the  assertion 
to  the  Allocate  relation.  This  assertion,  however,  does  not 
alter  the  conditions  Request  and  Avail  that  initiated  the 
rule's  firing.  Thus,  this  rule  may  conceptually  "fire 
forever"  unless  some  action  is  taken  to  disable  one  or  more 
of  its  conditions. 

The  deletion  is  used  for  this  purpose.  The  allocation 
rule  may  be  written  as: 

if  Request  (resource,  job).  Avail  (resource)  -> 

-•Request  (resource,  jot), 

-•Avail  (resource)  , 

Alloca  te  (resource ,  jot). 

The  deletions  -.Request  (resource ,  job)  and  -.Avail  (resource) 
remove  the  indicated  tuples  from  their  relations. 

The  preceding  actions — determine  a  pattern-match  of  a 
tuple  within  a  relation,  then  remove  the  tuple — is  a  typical 
sequence.  An  abbreviated  syntax  for  this  sequence  is  the 
cancel  operation.  Using  cancel  operations,  the  preceding 
rule  may  be  written: 

if  *Request  (resource,  job),  *Avail  (resource)  -> 

Allocate  (resource,  jot). 


The  absence  of  a  tuple  fro  m  a  relation  might  or  might 
not  be  interpreted  as  the  negation  of  its  presence.  If  one 
uses  a  "closed  world"  assumption,  then  absence  is  the  same 
as  negation.  The  logical  interpretation  of  an  absence  test 
is  dependent  on  the  programmer's  intent  and  assumptions. 

Free  variables  are  not  bound  in  an  absence  test. 
Consider  again  the  rule: 

if  -VTapeDrives  ( j,  4)  ->  .  .  . 

For  the  antecedent  to  be  true,  there  is  no  tuple  <j,  4>  in 

the  TapeDrives  relation.  Therefore,  the  free  variable  j 
will  remain  unbound. 

The  inquiry  and  absence  conditions  form  the  basis  for 
the  evaluation  of  the  current  state  of  the  system.  An  addi¬ 
tional  mechanism  is  provided  for  the  evaluation  of  state 
information.  This  mechanism  is  termed  a  constraint,  and  can 
be  any  Boolean  expression. 

Consider  the  case  where  one  is  interested  in  determining 
if  a  job  requires  more  than  5  tape  drives.  This  could  be 
expressed  as  : 

if  TapeDrives  (j ,  n),n>5->.  .  . 

where  the  expression  n  >  5  is  a  constraint.  The  join 

example  shown  previously  could  be  rewritten  as 

if  TapeDrives(  j  1,  n)  ,  Priority  (j2,  p)  ,  j  1  =  j  2  ->  .  .  . 

The  conseguent  portions  of  rules  alter  the  state  of  the 
system.  The  actions  of  the  conseguent  typically  update 
relations  in  some  way.  The  fundamental  actions  are  asser¬ 
tions  and  deletions. 

An  assertion  adds  a  tuple  to  a  relation.  Consider  the 
rule : 

if  Bequest  (resource,  job).  Avail  (resource)  -> 

Allocate  (resource,  jot). 


match  the  inquiry  against  the  tuples  of  the  relation.  Once 
a  logical  variable  has  become  bound  through  an  inquiry,  this 
binding  will  remain  in  effect  for  that  particular  rule. 

The  following,  more  complex,  inquiry  relies  on  variable 
binding: 

if  TapeDrives  ( j ,  n)  ,  Priority(j,  p)  ->  .  .  . 

The  comma  is  considered  as  a  logical  "and"  between  the  two 
inquiries.  Thus,  the  antecedent  of  this  rule  will  be  evalu¬ 
ated  as  true  if  tuples  exist  in  the  TapeDrives  and  Priority 
relations  such  that  the  first  member  of  each  tuple  is  the 
same.  This  corresponds  to  the  equality  join  of  relational 
database  systems. 

It  is  important  to  note  that  inquiries  are  existentially 
quantified.  An  inquiry  is  evaluated  as  "if  there  exists  a 
tuple  <x1,  xn>  in  relation  E,  return  true." 

It  is  also  important  to  note  that  the  logical  variable 
binding  done  during  pattern-matching  is  in  effect  only  for 
the  duration  of  the  rule.  The  scope  of  a  logical  variable, 
then,  is  the  rule  where  the  variable  occurs. 

Other  variables  may  have  more  permanent  bindings,  and 
behave  like  constants.  There  is  no  syntactic  distinction 
between  free  and  bound  variables.  To  avoid  confusion  in 
examples,  free  logical  variables  will  always  begin  with  a 
lower  case  letter,  bound  variables  and  constants  will  begin 
in  upper  case. 

Another  type  of  antecedent  condition  is  a  test  for  the 
absence  of  a  tuple.  This  condition  has  the  form 

if  iTapeDri ves { j,  4)  ->  .  .  . 

which  is  read  "if  it  is  not  the  case  that  a  tuple  <j,  4> 
exists  in  the  TapeDrives  relation."  If  the  tuple  pattern  is 
not  a  member  of  the  relation,  the  expression  is  evaluated  as 
true. 


\  ^  ^  T  *  .  ■  » '■  '  1  1  ■  l  m  m  m  m 


Relations  themselves  are  objects,  althouyh  they  are 
distinguished  by  having  an  intrinsic  value:  the  collection 
of  tuples  instantiating  the  relation.  As  objects,  relations 
may  be  members  of  tuples  and  participate  in  other  relations. 

D.  PATTERN-DIRECTED  FRODDCTION  HOLES 

The  relations  organize  the  primitives  of  the  system. 
Thus,  at  a  given  time,  the  state  of  the  system  is  character¬ 
ized  by  its  relations  and  the  entities  bound  through  these 
relations.  To  complete  the  model,  a  mechanism  must  be  used 
to  describe  state  transitions.  Pattern-directed  production 
rules  are  used  for  this  purpose. 

A  rule  is  a  pair  <a,  c> ,  where  a  is  termed  an  antecedent 
and  c  a  consequent.  An  antecedent  consists  of  Boolean 
conditions  that  pertain  to  the  state  of  the  system.  Tne 
consequent  consists  of  actions  that  will  be  executed  if  the 
conditions  of  the  antecedent  are  true.  Rules  are  written: 

if  <antecedent>  ->  <consequent>. 

A  condition  may  be  one  of  several  constructs.  The  most 
fundamental  is  the  inquiry.  An  inquiry  is  a  pattern-matched 
test  described  by  the  rule  that  is  performed  against  the 
relations  of  the  system.  As  an  example,  consider  the  job 
queue  again.  A  rule  may  be  desired  that  checks  for  jobs 
requesting  4  tape  drives.  This  could  be  expressed  as: 

if  TapeDrives ( j ,  4)  ->  .  .  . 

where  the  consequent  of  the  above  rule  is  not  shown.  The 
expression  TapeDri ves  (j,  4)  is  an  inquiry,  and  may  be  read 
as  "if  there  is  a  tuple  <entity,  4>  in  the  TapeDrives  rela¬ 
tion,  then  return  true  and  bind  the  entity  to  the  variable 
j."  The  symbol  j  in  this  example  is  an  unbound  logical 
variable,  which  is  considered  a  wild  card  in  an  attempt  to 
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•  Objects  are  subject  to  change  over  time. 

•  Objects  may  be  created  and  destroyed. 

The  distinction  between  objects  and  values  is  discussed  in 
[Bef.  15].  Subsequent  examples  should  help  to  illustrate 
the  role  of  objects  in  Omega. 

C.  A  BE1ATIOHAL  MODEL 

The  components  of  the  language  are  organized  according 
to  a  relational  model.  The  mcdel  is  consistent  with  rela¬ 
tional  terminology  introduced  by  Codd  [Bef.  16]. 

Consider  an  object  that  represents  a  queued  process 
waiting  for  an  operating  system  resource.  For  reference 
purposes,  the  object  must  be  named,  so  call  it  J. 
Associated  with  the  object  are  a  priority,  P,  and  a  tape 
drive  allocation  requirement,  T.  The  priority  and  resource 
requirements  are  values  that  must  be  associated  with  the 
job.  These  associations  may  be  described  by  a  Priority 
relation  and  a  TapeDrive  relation.  This  could  be  expressed 
as  Priority(J#  P)  ,  TapeDrives ( J ,  T)  .  In  these  expressions, 
the  pairs  <J,  P>  and  <J,  T>  are  called  tuples. 

A  tuple  is  an  ordered  collection  of  objects  and  values. 
Note  that,  unlike  relational  database  models,  named  attri¬ 
butes  are  not  used  to  describe  a  tuple.  Instead,  the 
members  of  a  tuple  are  described  by  relative  position  (order 
is  important),  by  value,  and  by  pattern-matching. 

A  relation  is  a  set  of  tuples.  Relations  are  described 
by  name,  and  through  pattern-matching.  As  a  set,  the  tuples 
of  a  relation  are  (1)  unique  and  (2)  unordered. 

Objects  serve  as  representative  place  holders  in  rela¬ 
tions.  The  state  of  an  object  is  determined  by  the  rela¬ 
tions  in  which  it  participates,  and  by  the  attributes 
associated  with  the  object  in  these  relations. 


II.  AN  INFORflAL  DESCRIPTION  OF  THE  LANGUAGE 


A.  GENEBA1 

This  chapter  provides  a  descriptive  summary  of  the 
features  of  the  Omega  language.  The  descriptions  are  mainly 
by  example,  and  serve  to  provide  a  feel  for  the  language 
constructs,  not  detail. 

The  material  in  this  chapter  is  based  on  the  work  of 
MacLennan.  The  philosophy,  informal  and  formal  semantics, 
and  original  syntax  of  the  language  are  introduced  in 
[Ref.  14].  Some  syntactic  and  semantic  differences  exist 
between  the  original  description  of  the  language  given  in 
[Ref.  14]  and  the  prototype  implementations.  Later  chapters 
will  deal  with  the  rationale  for  these  deviations.  The 
implementation  syntax  is  used  in  this  chapter  to  maintain 
consistency  with  with  the  remainder  of  this  thesis.  A 
description  of  the  implementation  syntax  is  contained  in 
Appendix  A. 

B.  OBJECTS  AND  VALDES 

The  entities  of  the  system  are  divided  into  values  and 
objects.  The  values  of  the  system  include  numerics  (inte¬ 
gers  and  reals) ,  character  strings,  and  lists.  Lists  are 
denoted  ty  square  brackets,  such  as: 

[  "a",  ”b" ,  [1,  2]]. 

Objects  are  referenced  by  name,  and  are  subject  to  the 
following  properties: 

•  Objects  are  unique. 

•  Objects  may  be  shared. 
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interpreter  organization,  data  representation,  and  control 
strategies  used  in  the  implementation,  and  how  these  charac¬ 
teristics  impact  on  the  performance  of  the  system. 

This  work  is  a  prototyping  effort.  Because  of  the 
experimental  nature  of  the  language,  various  extensions  and 
modifications  were  required  on  preliminary  designs.  To 
support  this  experimentation,  two  prototypes  for  the  inter¬ 
preter  were  written.  The  first  was  a  throw-away  prototype 
written  in  Franz  LISP.  The  second  was  a  more  complete, 
incremental  development  written  in  C. 

G.  A  SUBJECTIVE  EVALUATION 

As  a  secondary  emphasis,  some  attention  is  given  in  this 
work  to  the  evaluation  of  Cmega  as  a  general-purpose 
programming  language.  While  these  observations  are  largely 
subjective,  they  provide  some  insight  into  the  implementa¬ 
tion  problems  associated  with  these  early  prototypes. 
Having  prototype  interpreters  up  and  running  has  also 
provided  an  opportunity  for  experimentation  with  Omega 
programming  that  may  prove  useful  in  the  early  evaluation  of 
features  in  the  language. 


and  expert  systems  such  as  MYCIN  [Ref.  10 j,  DENDRAL 
[Ref.  11],  and  PROSPECTOR  [Ref.  12]. 

Prolog  is  a  general-purpose  language  which  uses  rule- 
based  theorem  proving  as  the  computational  metaphor 
[Ref.  13].  Distinct  from  the  applicative  languages,  Prolog 
uses  pattern-matching  instead  of  the  procedure  call  to 
determine  the  applicability  cf  rules  and  the  resulting 
computations. 

E.  A  COMBINED  APPROACH 

The  preceding  discussion  highlights  the  following 
features  offered  by  these  languages: 

•  Function  application  provides  a  powerful,  regular  mecha¬ 
nism  for  stateless  computation. 

•  An  ob ject-oriented  approach  provides  an  effective  organ¬ 

ization  for  data  and  procedures  which  is  useful  in 
representing  temporal  relationships  and  real-world 

objects. 

«  Rule-based  pattern-matching  systems  have  provided  an 
alternative  way  for  expressing  complex  knowledge 

representation. 

The  Omega  language  [Hef..  14]  represents  an  approach  that 
combines  these  features  into  a  single  language  framework. 


F.  AN  IMPLEMENTATION  STUDY 

The  emphasis  of  this  thesis  is  on  the  implementation  of 
an  interpreter  for  the  Omega  language.  As  an  implementation 
study,  the  focus  is  on  language  architecture — those  charac¬ 
teristics  of  the  language  that  were  conducive  or  that 
presented  obstacles  to  efficient  implementation.  Of  partic¬ 
ular  interest  in  this  effort  are  the  characteristics  of 


by  Smalltalk  [Eef.  5].  Smalltalk  partitions  the  program¬ 
mer's  model  into  collections  of  objects  called  classes. 
Objects  have  a  state  associated  with  them,  and  the  methods 
{procedural  information)  of  the  class  determine  an  object's 
computational  behavior.  Both  data  and  procedural  informa¬ 
tion  are  organized  around  the  object. 

The  object-oriented  approach  allows  certain  important 
capabilities.  Foremost,  the  concept  of  state  is  fully 
ingrained  in  the  language.  The  simulation  approach  facili¬ 
tates  the  modeling  cf  real-world  activities,  with  concur¬ 
rency  readily  handled  through  the  mechanism  of  communicating 
objects. 

Associated  with  the  class  mechanism  in  Smalltalk  is  the 
concept  of  inheritance.  When  a  new  object  is  created,  it 
obtains  certain  default  state  and  behavioral  characteristics 
from  its  class.  In  the  functional  languages,  combinatorial 
power  is  obtained  through  subordinate  function  application 
and  the  use  of  functionals.  In  the  object-oriented 
approach,  combinatorial  power  is  obtained  through  composi¬ 
tion  of  new  objects  from  existing  ones,  and  through 
inheritance. 

D.  INFERENCE  SYSTEMS  AND  LOGIC  PBOGBAMMING 

Inference  systems  have  developed  through  artificial 
intelligence  efforts  at  cognitive  modeling,  knowledge  repre¬ 
sentation,  and  theorem  proving.  Based  on  the  early  produc¬ 
tion  system  of  Post  [Eef.  6],  these  systems  use  rules, 
similar  to  logical  implication,  that  provide  the  computa¬ 
tional  framework  for  a  program.  Eule-based  organization  has 
been  described  by  Newell  [Eef.  7],  and  an  early  language 
based  on  the  concept  was  Hewitt's  PLANNEE  [Eef.  8]- 
Numerous  rule-based  systems  have  since  been  developed,  with 
notable  examples  being  theorem  provers  such  as  AM  [Eef.  9], 
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languages,  object-oriented  languages,  and  rule-based  infer¬ 
ence  languages. 

B.  APPLICATIVE  LANGUAGES 

Applicative  languages  use  the  application  of  a  function 
to  its  arguments  as  the  focus  for  computation.  These 
languages  are  typified  by  pure  LISP  [Bef.  2],  and  by  later 
functional  languages  such  as  FP  [Ref.  1]  and  KRC  [Bef.  3], 

The  strengths  of  the  applicative  languages  are  exempli¬ 
fied  by  arithmetic  expressions.  These  strengths  include 
clear  interfaces  between  computational  units,  relative  inde¬ 
pendence  of  evaluation  order,  and  a  semantic  regularity  that 
lends  itself  to  simple  verification  and  proof  techniques. 

Functionals,  functions  which  receive  functions  as  argu¬ 
ments  and  return  functions  as  results,  provide  a  mechanism 
for  the  combination  of  simple,  primitive  computational  units 
into  collections  of  arbitrary  power  and  complexity. 

The  applicative  languages  achieve  their  predictability 
largely  from  the  prohibition  of  side-effects  during  computa¬ 
tion.  This  characteristic  limits  the  problem  domains  to 
which  applicative  solutions  can  be  readily  applied.  Like 
the  arithmetic  expression,  applicative  languages  cannot 
readily  describe  the  notion  of  state.  There  is  no  explicit 
notion  of  time  in  an  arithmetic  expression,  and  applicative 
languages  are  correspondingly  weak  in  maintaining  temporal 
relationships.  This  characteristic  limits  the  utility  of 
applicative  languages  in  inherently  state-oriented  applica¬ 
tions.  Such  applications  include  operating  system  activi¬ 
ties,  data  base  management,  and  discrete  simulation. 

C.  OBJECT-ORIENTED  LANGUAGES 


The  object-oriented  languages  have  developed  from  simu¬ 
lation  languages  such  as  Simula  [Ref.  4],  and  are  typified 


I.  INTRODUCTION 


A.  BACKGROUND 

Two  major  issues  in  programming  language  design  can  be 
characterized  as  abstraction  and  architecture.  In  this 
context,  abstraction  refers  to  the  ability  of  the  language 
to  capture  the  ideas  of  the  programmer.  It  is  a  measure  of 
expressiveness  or  semantic  power.  Architecture  refers  to 
those  language  characteristics,  both  organizational  and 
syntactic,  that  affect  practical  usage.  This  includes  ease 
of  use  for  the  programmer  as  well  as  the  potential  for  effi¬ 
cient  implementation.  Thus  an  important  goal  for  a  program¬ 
ming  language  is  to  combine  a  powerful  abstraction  ability 
with  an  effective  language  archit ecture. 

Conventional  languages  have  suffered  in  both  of  these 
areas.  These  languages  focus  on  the  use  of  assignment 
statements  for  computation,  and  execution  consists  of  the 
sequential  flow  of  program  control  between  assignment  state¬ 
ments.  John  Backus  described  these  "von  Neumann"  languages 
as  excessively  complex  and  weak,  whose  word-at-a-time 
conceptual  basis  has  created  an  "intellectual  bottleneck" 
[Ref.  1 :  p.  615].  These  languages  are  oriented  more  towards 
the  word-at-a-time  stored  program  computer  than  towards  the 
problem  domains  they  attempt  tc  satisfy.  Thus  they  have 
poor  abstraction  ability.  While  simple,  elegant  imperative 
languages  such  as  Pascal  have  enjoyed  popularity,  the  need 
for  increased  power  has  resulted  in  complex  languages  such 
as  Ada.  Such  languages  have  attained  semantic  power  at  the 
expense  of  architectural  effectiveness. 

Several  alternatives  to  the  von  Neumann  languages  have 
been  developed.  Of  interest  in  this  thesis  are  applicative 
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returned  as  the  result  of  the  procedure  call  in  the  expres¬ 
sion  where  the  call  was  invoked . 

The  procedure  call  as  shown  in  the  preceding  example  is 
similar  to  the  function  invocation  described  earlier-  Both 
invocations  may  be  used  in  expression s,  returning  results 
that  are  incorporated  in  expressions.  The  underlying  mecha¬ 
nisms  of  the  function  and  procedure  call  are  different, 
however.  In  particular,  the  procedure  call  relies  on  the 
use  of  rules  to  describe  its  actions,  and  therefore  relies 
on  side  effects. 

The  server  rule  in  this  example  may  be  triggered  by 
either  an  assertion  cr  procedure  call  involving  the  Bequest 
relation.  There  is  nothing  about  the  form  of  the  rule  that 
indicates  its  use  in  procedure  calls.  By  convention, 
however,  such  rules  must  use  the  leftmost  member  of  a  tuple 
in  the  enabling  relation  as  the  receiver  of  the  response. 

The  value  returned  by  a  procedure  call  does  not  have  to 
be  used  in  an  expression.  In  the  following  example: 

if  *Function  ( job,  c)  ,  -»CodeTable  (c,  def)  -> 

Display  ("Illegal  function  code"} 

an  assertion  to  the  Display  relation  is  assumed  to  eventu¬ 
ally  cause  the  message  to  be  displayed  at  the  user's 
terminal.  The  value  returned  by  the  calling  mechanism  is 
used  for  synchronization  only,  and  is  otherwise  ignored. 

G.  SEQUENTIAL  CONTBCI 

In  the  preceding  examples,  no  particular  order  was 
assumed  for  the  evaluation  of  conditions  in  the  antecedent, 
and  no  order  is  assumed  for  the  execution  of  the  actions  in 
the  consequent.  These  actions  may  be  considered  to  be 
asynchronous  and  concurrent.  This  situation  becomes  ever, 
more  unstructured  when  a  collection  of  rules  is  being 
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considered  for  evaluation.  Once  again,  no  evaluation  order 
is  assumed. 

The  sequential  block  provides  a  mechanism  for  the 
programmer  to  specify  an  explicit  order  for  rule  evaluation. 
This  is  shown  in  the  following: 

if  *Request(a,  r) ,  -*Avail  (r)  -> 

{  ->  Display ("Wai tin g  for  resource...”}; 

if  *Queue{r,  1)  -> 

Queue  (r,  cons[a,  1]); 

} 

The  effect  of  this  rule  is  to  display  a  message  and  to  add 
the  requesting  agent  to  a  queue  for  the  desired  resource. 
The  sequential  block  guarantees  that  the  rules  within  the 
{}  's  will  be  evaluated  in  the  order  shown. 

As  the  example  indicates/  the  variables  bound  in  the 
antecedent  retain  their  bindings  in  the  sequential  block. 
The  blocks  may  be  nested,  with  the  bindings  of  free  vari¬ 
ables  extending  to  inner  blocks. 

In  this  example,  the  antecedent  is  omitted  in  the 
Display  rule.  This  is  equivalent  to  a  true  antecedent. 
When  writing  such  rules,  the  notation  may  be  shortened  to: 

Display  [x] 

which  is  equivalent  to: 

if  TRUE  ->  Display  £x}  . 


H.  CONTROLLING  THE  NAHE  SPACE 

The  previous  descriptions  give  a  simple  mechanism  for 
the  binding  of  logical  variables.  The  rules  may  be  summa¬ 
rized  as: 
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•  The  scope  of  variables  bound  in  an  antecedent  extends  to 
the  consequent  for  a  given  rule. 

•  If  sequential  blocks  are  nested,  oindings  made  in  outer 
blocks  extend  to  inner  blocks. 

The  previous  examples  have  suggested  a  more  global  binding 
mechanism,  as  indicated  in  the  use  of  relation  names.  The 
Request  relation  name  is  globally  bound  in  this  manner.  The 
mechanism  through  which  global  names  are  managed  is  the 
directory. 

A  directory  is  a  named  collection  of  pairs,  <name,  defi¬ 
nition^  where  the  name  entry  is  a  character  string  and  the 
definition  is  an  object  or  value  representation  associated 
with  the  name.  The  directory  may  be  thought  of  as  a  named 
symbol  table. 

MacLennan  [Ref.  14:  pp.  34-35]  describes  a  directory 
structure  with  two  partitions:  public  and  private.  Names 
defined  in  the  public  partition  are  globally  visible  to 
agents  other  than  the  owner.  Names  defined  in  the  private 
partition  are  visible  only  to  the  owner. 

A  simple  elaboration  of  this  mechanism  provides  a  flex¬ 
ible  partitioning  scheme.  The  public  and  private  partitions 
are  associated  with  named  directories.  These  directories 
are  organized  into  named  classes,  not  necessarily  disjoint. 
In  addition,  there  is  a  notion  of  a  "current  directory" 
similar  to  that  in  UNIX. 

The  context  of  a  name,  then,  is  determined  by  the 
current  directory  in  which  the  name  is  defined.  Rhen  evalu¬ 
ating  the  binding  of  a  name,  the  current  directory  public 
and  private  partitions  are  searched  for  an  entry.  If  this 
local  search  fails,  the  public  directories  associated  with 
the  classes  of  the  current  directory  are  searched.  The 
class  structure  defines  a  search  path  for  variable  lookup. 


28 


To  illustrate  these  points,  consider  the  definition  of 
the  Bequest  relation  of  previous  examples.  Suppose  the 
current  directory  is  "ServerDatabase, "  a  member  of  the  class 
"Servers."  The  relation  is  created  and  named  by: 

Define  {Private,  "Bequest",  NewrelQ}. 

The  Define  procedure  call  makes  a  <name,  definition>  entry 
into  a  directory  partition.  The  Newrelf}  procedure  call  is 
assumed  to  return  a  unique  system  identifier  that  represents 
a  relation.  The  definition  shewn,  therefore,  would  create 
the  relation  and  bind  a  name  to  that  relation  in  the  private 
partition  of  the  current  directory. 

Such  a  server  relation  would  be  of  more  general  utility 
than  a  private  definition  allows.  Before  the  relation  is 
opened  to  broader  access,  an  access  control  mechanism  is 
necessary. 

This  control  is  achieved  by  associating  capabilities 
with  each  relation.  When  a  relation  is  created  with  the 
Newrel{}  procedure  call,  full  capabilities  are  associated 
with  the  relation  identifier.  These  capabilities  include 
read,  add,  and  delete.  &  public  definition  of  the  Bequest 
relation  may  be  accomplished  as  follows: 

Define  {Public,  "Bequest",  AddOnly  {Request} }  . 

The  AddOnly  procedure  call  references  the  system  identifier, 
with  full  capabilities,  that  has  been  bound  to  the  private 
name  Bequest.  A  copy  of  this  identifier  is  made  with 
reduced  capabilities  but  still  referring  to  the  same  rela¬ 
tion.  This  new  identifier  is  then  installed  in  the  public 
directory  for  general  access.  This  technique  of  capability 
addressing  is  based  on  the  werk  of  Dennis  and  Van  Horn 
[Ref.  17]. 

Objects  are  created  in  a  similar  manner: 

Define  {Private,  "Jobl",  Kewotj{}}. 


The  NewobjQ  procedure  returns  a  unique  identifier  to  be 
associated  with  an  object.  Objects  created  in  this  manner 
have  no  intrinsic  value  associated  with  them,  and  there  is 
no  access  control  associated  with  their  identifiers. 

I.  A  PROGRAMMING  SYSTEM 

The  language  elements  described  may  be  adapted  to  a 
general  programming  system.  To  simplify  interaction  with 
the  system,  [fief.  14:  p.  39]  suggests  the  use  of  rules  as  a 
command  language. 

While  syntactically  similar  to  production  rules,  these 
command  rules  are  subject  to  a  slightly  different  method  of 
interpretation.  If  a  user  wishes  to  query  the  contents  of 
the  Allocate  relation,  this  may  be  accomplished  by: 

if  Allocate  (x)  ->  Display  {x}  . 

If  analyzed  as  a  production  rule,  however,  this  query  would 
be  a  "fire  forever"  type.  Rules  such  as  this  require  a 
different  method  of  evaluation:  test,  fire,  and  forget. 

The  command  rules  represent  the  second  class  of  rules  in 
the  system.  The  first  class  of  rules  is  that  of  the  produc¬ 
tion  rules  previously  described.  These  rules  are  termed 
active  rules.  Active  rules  comprise  a  body  of  state  tran¬ 
sition  information  that  continuously  monitors  the  relations 
referenced  in  their  antecedents.  Command  rules  are  initi¬ 
ated  by  an  event  in  the  system,  and  only  evaluated  once. 
The  initiating  event  in  previous  example  was  the  entry  of  a 
command  rule  at  the  terminal. 

The  active  rules  are  distinct  from  command  rules,  yet 
the  command  rules  provide  the  interactive  interface  between 
the  user  and  the  system.  The  two  categories  are  bridged 


A  rule  denotation  is  a  syntactic  representation  of  rules 
as  data.  A  potential  active  rule  may  be  described: 

Define  {Private,  ’’ReguestRules” , 

« 

if  *Reguest(a,  r)  ,  *Avail(r)  -> 

Allocate  {a,  r)  ,  a  (r) 

» 

}. 

The  denotation  is  expressed  between  <<  >>’s,  which  is  inter¬ 
preted  as  ’’parse  but  don’t  evaluate.”  This  definition  binds 
the  parse  tree  associated  with  the  server  rule  to  the  name 
’’ReguestRules"  in  the  private  directory  partition. 

A  rule  denotation  bound  in  this  manner  is  a  data  struc¬ 
ture  subject  to  manipulation  by  the  system.  To  make  the 
transition  from  this  passive  status  to  active  status,  the 
rule  denotation  is  activated: 

Activate [ServerRules] . 

At  this  point,  the  rules  expressed  in  the  denotation  are 
moved  to  active  status  and  enter  a  continuous  test-fire 
cycle. 

This  process  is  similar  in  many  respects  to  program 
development  in  a  more  conventional  system.  The  command 
entry  of  the  rule  corresponds  to  the  creation  of  a  program 
source  file,  and  activation  corresponds  to  compilation, 
linking,  and  loading. 


III.  DESIGN  ISSUES  AND  GOALS 


A.  THE  ARCHITECTURE  OF  RULE-BASED  SYSTEMS 

Omega  is  a  production-rule  system.  Davis  [fief.  18:  p. 
301]  describes  these  systems  in  terms  of  three  components: 

•  A  rule  base.  Omega's  set  of  active  rules. 

•  A  database.  The  set  of  relations  and  their  contents. 

•  An  interpreter.  The  mechanism  for  rule  selection  and 
execution. 


B-  ROLE  SELECTION  AND  CONFLICT 

The  control  cycle  of  the  interpreter  processes  rules  in 
a  continual  recognize/act  cycle.  The  recognition  phase 
consists  of  selection  and  conflict  resolution  [Ref.  18:  p. 
325]. 

Omega  uses  a  forward-chaining  method  for  rule  selection. 
This  method,  described  in  the  examples  of  the  previous 
chapter,  compares  the  antecedent  of  the  rule  to  the  data¬ 
base.  A  rule  is  selected  when  an  appropriate  match  is 
found. 

In  general  terms,  production  systems  produce  a  conflict 
set  for  each  recognize/act  cycle  [Ref.  18:  p.  325].  The 
conflict  set  consists  of  all  active  rules  whose  antecedents 
are  true  given  the  current  state  of  the  database.  In  the 
Omega  system,  the  resolution  of  the  conflict  set  is  simple. 
For  a  given  cycle,  each  rule  within  the  conflict  set  will  be 
tested  and,  if  its  conditions  are  true,  will  fire.  The 
order  in  which  the  rules  in  the  conflict  set  are  tested  is 
not  specified. 
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The  rules  of  Omega  are  indivisible  once  they  are 
selected  [Ref.  14:  pp.  19-20].  To  illustrate  this  point, 
suppose  the  following  rules  were  active: 

if  ^Request  (a)  ->  Allocate  {a.  Red). 

if  *Request  (a)  ->  Allocate  (a.  Blue). 

Under  this  selection  strategy,  only  one  of  these  rules  will 
fire  (assuming  there  is  only  cne  tuple  in  Request) .  The 
indivisible  nature  of  rule  evaluation  guarantees  at  least 
mutual  exclusion  for  rules  such  as  these.  Since  the  evalua¬ 
tion  order  for  these  rules  is  not  defined,  a  more  explicit 
antecedent  would  have  to  be  designed  to  establish  conflict 
priorities. 

The  rule  selection  and  conflict  strategies  support  a 
powerful  execution  mechanism.  Using  this  approach,  the 
procedural  information  of  the  system  is  sensitive  to  the 
state  of  the  database,  and  responds  accordingly.  This 
behavior  is  more  complex  than  a  procedure-oriented  system, 
where  the  thread  of  execution  control  is  more  closely  tied 
to  the  procedural  code  organization. 

The  complexity  of  rule  testing  has  performance  penalties 
associated  with  the  precision  of  rule  selection.  By  preci¬ 
sion,  we  refer  to  the  number  of  rules  whose  antecedent 
conditions  are  true  compared  to  the  number  of  rules  selected 
for  testing.  The  most  inefficient  and  most  obvious  level  of 
precision  is  to  scan  the  entire  rule  base  on  every  cycle. 
We  call  this  a  global  sweep  strategy.  At  the  opposite 
extreme  is  a  selection  strategy  that  produces  only 
"successful"  rules  for  test. 

C.  PATTERH-BATCHIHG 

At  the  heart  of  the  rule  evaluation  process  is  pattern¬ 
matching.  Given  the  form  of  a  rule: 

if  S  (e  1 )  ->  .  .  . 
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a  description  the  pattern-matching  process  for  each  candi¬ 
date  tuple  x  in  R  is: 

match[  x,  el  ]: 

if  x=Nil  and  e1=Nil 
return  TRUE 

else  if  x=Nil  or  e 1=Nil 
return  FALSE 
else  if  el  is  an  atom 
if  el  is  unbound 
iind[e1,  x] 

history  :=  cons[e1,  history] 
return  TRUE 
else  if  el  =  x 

return  TRUE 

else 

return  FALSE 

endif 

else  if  match[first[  x  ],  first[e1]] 

return  match£  rest£  x  ],  rest£e1]] 

else 

return  FALSE 

endif 
end  match 

This  description  assumes  a  LISP-like  list  representation  for 
tuples. 

This  pattern-matching  process  is  expensive. 

Incorporating  this  method  at  the  heart  of  the  interpretation 
cycle  presents  a  significant  design  challenge. 
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D.  HOSE  CONVENTIONAL  ISSUES 

3esides  these  unusual  design  issues.  Omega  is  subject  to 
the  same  design  requirements  as  more  conventional  languages. 
These  include: 

•  A  parser  and  lexical  scanner  tor  command/rule  input. 

•  A  procedure- oriented  evaluation  component  for  applica¬ 
tive  expressions. 

•  A  flexible  symbol  table  mechanism  for  the  support  of 
directories. 

•  Dynamic  typing. 

•  Dynamic  memory  allocation  and  reclamation. 


E.  DESIGN  GOALS 

The  design  goals  for  the  prototypes  are  grouped  into  the 
areas  of  feature  implementation,  relation  representations, 
efficiency,  and  evaluation. 

1  •  Feature  Implementation 

The  major  objective  in  this  work  was  the  construc¬ 
tion  cf  working  prototype  interpreters  for  the  language.  A 
progressive  schedule  was  developed  that  sought  to  implement 
the  following  features: 

•  Canonical  Rules.  This  phase  includes  the  development  of 
the  inquiry,  absence,  assertion,  and  deletion  functions 
for  basic  rule  interpretation. 

•  Function  definition  and  evaluation. 

•  Procedure  calls. 
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•  Cancel  operations. 

•  Sequential  blocks. 


2.  delation  Representations 

Relations  and  the  operations  defined  on  them  are  the 
central  components  of  the  Omega  system.  To  support  flexi¬ 
bility  in  relations,  a  variety  of  representations  is  desir¬ 
able.  Such  representations  could  range  from  a  simple  list 
structure  to  a  relational  database  management  system  (DBMS)  . 
To  reduce  the  problems  associated  with  multiple  representa¬ 
tion,  the  relation  interface  must  be  clear:  an  abstract 
data  type,  with  primitive  operations  defined  for  data 
access. 

3 .  Efficiency 

The  Omega  language  was  developed  as  a  general- 
purpose  language,  capable  of  prototyping  programming  envi¬ 
ronments  and  a  variety  of  system-level  functions.  This 
orientation  makes  execution  efficiency  an  important  imple¬ 
mentation  issue.  The  goal  was  to  obtain  a  level  of 
efficiency  comparable  to  a  LISP  system. 

Efficiency  was  considered  mainly  in  terms  of  execu¬ 
tion  speeds.  In  those  cases  where  a  space-f or-time  trade¬ 
off  was  available,  it  was  made. 

4 .  Evaluation 

The  final  goal  for  the  prototypes  was  evaluation. 
This  evaluation  centered  on  performance:  how  control  strat¬ 
egies  and  data  structures  affect  execution  time.  A  second 
evaluation  area  was  to  determine  the  utility  of  language 
features  through  programming  experience. 


I¥.  A  LISP  PHOTOTIPE 


A.  WHI  LISP? 

The  design  issues  for  Omega  led  to  the  decision  to  write 
a  quick  prototype  for  the  exploration  of  high-level  design 
decisions.  The  high-level  concerns  were  the  interpreter 
organization,  selection  strategies  for  rules,  and  the  repre¬ 
sentation  of  objects,  relations,  and  directories. 
Efficiency  was  not  a  design  goal  for  this  prototype. 

Franz  LISP  was  selected  as  the  initial  prototyping 
language.  This  selection  was  made  for  the  following 
reasons: 

•  Availability.  Franz  LISP  was  available  on  the  VAX 
11/780  system  being  used  for  this  work.  We  were 
familiar  with  Franz  LISP,  and  the  implementation  is 
well-done.  The  system  includes  a  reliable  interpreter, 
compiler,  and  debugging  package. 

•  Symbolic  facilities  aid  in  pattern-matching.  The  heart 
of  the  Omega  design  is  the  pattern-matching  process. 
The  symbolic  manipulation  facilities  of  LISP  allow  these 
algorithms  to  be  programmed  quickly. 

•  Dynamic  typing.  The  dynamic  typing  of  LISP  corresponds 
well  with  the  typing  of  Omega. 

•  Memory  management.  Memory  management  is  transparent 
under  LISP.  While  these  issues  can  impact  heavily  on 
system  performance,  they  are  complex  and  distracting  to 
early  prototyping. 

•  Debugging.  The  debugging  facilities  of  Franz  LISP  are 
excellent,  and  superior  to  any  other  development 


environment  available  at  the  time.  In  a  prototyping 
project,  extensive  debugging  is  essential  to  cope  with 
constant  design  and  coding  changes. 

B.  ORGANIZATION 

The  interpreter  is  organized  like  a  classic  LISP  inter¬ 
preter.  The  organization  is  based  on  the  description  given 
in  Chapter  1 1  of  [Ref.  19]. 

The  top  level  consists  of  a  r ead-evaluate-sweep  loop. 
The  read  function  is  a  command  rule  parser.  Commands  are 
entered  at  the  terminal,  parsed,  and  an  instruction  list  is 
generated.  This  instruction  list  is  passed  to  the  evalua¬ 
tion  function  for  execution.  The  sweep  function  processes 
any  active  rules  that  are  ready  to  fire  after  the  actions  of 
the  r ead-evaluate  phases  are  complete. 

C.  THE  LEXICAL  SCANNER  AND  PARSER 

The  reader  consists  of  a  lexical  scanner  and  parser. 
Instead  of  evaluating  input  as  LISP  expressions,  the  reader 
accepts  free-format  input  using  the  Omega  grammar. 

1  •  The  Lexical  Scanner 

A  character  reader  function  is  used  to  pass  a  list 
of  characters  to  the  scanner.  This  reader  function  uses  the 
character  input  facility  of  Franz  LISP  [Ref.  20:  pp. 
5. 6-5.7].  As  each  character  is  read,  it  is  added  to  an 
input  character  list.  The  complete  character  list  is 
passed  to  the  scanner.. 

The  scanner  processes  the  input  character  list  to 
recognize  tokens.  When  recognized,  a  character  list  is 
compressed  into  a  token  (LISP  atom)  using  the  implode  func¬ 
tion  [Ref.  20:  p.  2.11].  The  final  output  of  the  scanner  is 
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a  list  of  tokens  built  up  in  this  manner.  It  is  this 
complete  list  of  tokens  that  is  passed  to  the  parser. 

The  token  classes  consist  of  identifiers,  constants, 
and  delimiters.  Constants  are  limited  to  integers  and 
strings.  Once  a  constant  token  is  recognized  and 
constructed,  a  denotation  function  transforms  the  symbol 
into  a  LISP  integer  or  string  atom. 

The  separation  of  the  scanner  from  its  supporting 
reader  function  allows  the  same  routines  to  read  from 
multiple  sources.  Two  reader  functions  are  used:  one  for 
console  input  and  one  for  file  input.  The  file  input  func¬ 
tion  is  used  to  support  command  rule  entry  from  text  files, 
similar  to  the  load  function  of  Franz  LISP  [Ref.  20:  p. 
5.5]. 

When  receiving  console  input,  the  reader  needs  to 
distinguish  the  end  of  input  for  a  command.  Successive 
carriage  returns  are  recognized  as  this  termination 
condition. 

2 .  The  Parser 

A  single-pass,  recursive  descent  parser  is  used  to 
process  the  token  list  produced  by  the  scanner.  As  a 
construct  is  recognized,  an  operator  symbol  is  created 
which,  along  with  its  operands,  is  added  to  the  parser’s 
output  list.  The  parser  receives  a  token  list  as  input,  and 
returns  an  operator/operand  list  as  output. 

The  output  list  for  the  parser  is  a  simplification 
of  the  abstract  syntax  for  the  language.  Consider  the 
following  input: 

if  *R1  (x)  ,  R2  (x)  ->  R3  (x)  . 

This  rule  is  reduced  to  a  token  list  by  the  scanner  and 
input  to  the  parser.  The  parser  output  for  this  rule  would 
be  the  following  LISP  expression: 
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scanner  and  parser  written  in  C,  and  integrated  into 
Franz  LISP  as  a  foreign  function  [Ref.  20:  pp.  8.4-8. 8]. 

•  Improved  control  strategies.  More  precise  rule  selec¬ 
tion  strategies  impact  heavily  on  performance. 

•  More  efficient  LISP.  Franz  LISP  offers  alternatives  to 
the  simple  list  structures  used  in  this  prototype.  An 
analysis  of  the  prototype  performance  could  be  performed 
to  pinpoint  areas  for  LISP  code  optimization. 

The  LISP  prototype  was  intended  to  be  a  throw-away 
implementation.  While  numerous  improvements  are  possible  in 
this  prototype,  the  performance  of  the  LISP  interpreter 
becomes  a  final  limitation.  An  implementation  in  a  lower- 
level  language  offers  the  potential  for  data  structures,  i/o 
facilities,  and  memory  management  techniques  that  are  more 
closely  tuned  to  the  requirements  of  Omega. 

An  important  decision  in  the  life  of  a  throw-away  proto¬ 
type  is  when  to  stop.  This  prototype  was  abandoned  after 
the  implementation  of  a  limited  but  fundamental  set  of 
features.  The  prototype  was  revised  numerous  times,  but 
with  a  minimal  expense  in  coding  time  and  implementation 
complexity.  While  many  aspects  of  the  interpreter  design 
changed  in  the  follow-on  implementation,  the  contributions 
of  this  prototype  to  the  next  were  substantial. 
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The  prototype  implemented  a  simple  list  representation 
for  relations,  and  assisted  in  the  identification  of  primi¬ 
tive  operations  required  to  manipulate  relations.  Of 
particular  interest  was  the  pattern-matching  algorithm. 
While  the  implementation  was  flawed,  the  basic  algorithm  was 
useful  in  the  follow-on  prototype. 

The  iterative  backtracking  algorithm  was  more  complex 
than  necessary.  The  stacks  used  to  support  backtracking 
suggested  a  recursive  algorithm  as  a  possible  alternative. 

The  design  chosen  for  the  parser  was  a  poor  one.  The 
steps  of  creating  a  character  list,  then  a  token  list,  and 
finally  an  instruction  list,  were  time  consuming.  The 

requirement  to  scan  the  token  list  for  the  presence  of  the 
"->"  token  worsened  the  already  poor  performance  of  the 
parser. 

The  interpreter  used  the  crudest  possible  control 
strategy,  and  tested  every  rule  on  each  iteration  of  the 
sweep  cycle.  This  control  strategy  has  the  obvious  advan¬ 
tage  of  simplicity,  but  the  performance  is  unacceptable. 
The  control  strategy,  together  with  the  slow  parsing  speed, 
resulted  in  a  sluggish  system  response,  even  with  a  small 
number  of  active  rules.  In  one  test  case,  the  parser 
required  13  seconds  to  process  a  33  line  rule  file;  with  an 
active  rule  list  of  about  20  rules,  a  simple  Display  command 
took  2  seconds  to  execute. 

It  was  anticipated  that  the  performance  of  this  proto¬ 
type  would  be  poor,  and  so  it  was.  This  is  not  a  reflection 
of  LISP  as  an  implementation  language.  No  attempt  was  made 
to  write  efficient  LISP,  and  substantial  improvements  can 
probably  be  made.  Potential  areas  for  improvement  are: 

•  An  improved  parser.  The  character  i/o  in  Franz  LISP 
lends  itself  to  the  inefficient  implementation  used  in 
the  prototype.  A  possible  improvement  would  be  a 
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When  the  interpreter  begins  execution,  the  following 
events  occur: 

•  The  root  directory  is  loaded  into  LISP. 

•  An  Omega  initialization  file  is  parsed  and  evaluated. 

•  The  interpreter  begins  its  read-evaluate-sweep  cycle. 

The  initialization  file  contains  Omega  command  rules 
that  allow  the  implementation  of  system  functions  with 
rules.  These  rules  are  defined  by  the  following  assertions: 

Root  ("Activate" ,  Newrelf  ])  . 

ActiveRules  (Par  se[  F read [  "sysgen.  rul"  ]  ])  . 

The  assertion  to  the  ActiveRules  relation  initializes  the 
system's  set  of  active  rules  to  those  contained  in  the  file 
"sysgen. rul.”  These  initialization  rules  consist  of: 

if  *Define(dir,  name,  def)  ->  dir  (name,  def)  . 

if  ^Activate (newrules)  ,  *ActiveRules (oldruies)  -> 
ActiveRules  (Append[  ol  drules,  newrules])  . 

These  rules  and  definitions  are  sufficient  to  set  up  a 
minimum  system.  As  shown  by  the  rules  for  Define  and 
Activate,  it  is  possible  to  express  system  functions  as 
rules.  To  expand  these  functions,  more  rules  may  be  defined 
and  added  to  the  active  rule  list. 

H.  1ESS0HS  LEABHED 

This  early  prototype  was  instructive,  both  in  those 
functions  which  worked  well  a rd  in  those  functions  which 
performed  poorly. 

The  major  benefit  was  the  implementation  of  a  top-down 
design.  The  read-evaluate-sweep  cycle  demonstrated  that  a 
recursive,  LISP- like  interpreter  design  was  useful  for 


G.  A  BOOT  SYSTEM 


After  the  implementation  of  the  basic  rule  interpreter, 
it  was  necessary  to  identify  a  minimum  set  of  definitions  to 
support  a  working  system.  When  such  a  system  becomes  opera¬ 
tional,  additional  features  can  be  added  through  rules 
defined  in  Omega. 

The  foundation  of  the  naming  mechanism  is  the  Define 
relation.  No  rules,  relations,  or  constructs  may  be  added 
to  the  system  without  the  use  of  Define.  To  accommodate 
names  that  are  added  as  the  system  grows,  a  minimum  of  a 
single  directory  is  necessary. 

In  this  prototype,  a  root  directory,  defined  in  LISP, 
contains  the  initial  bindings  required  by  the  interpreter. 
The  root  directory  initially  contains  the  bindings  for  the 
Define  relation  and  the  active  rule  list.  This  directory 
also  contains  a  reference  to  itself:  a  binding  for  the  name 
"root ." 

To  support  the  definition  cf  system  functions  in  IIS?, 
the  names  of  these  functions  are  pre-defined  at  the  time  of 
system  initialization. 

The  initial  root  directory  appears  as: 

(setg  root  * ( 

("Boot”  root) 

("ActiveBules"  ActiveEules) 

("Cons"  cons) 

("First"  car) 

("Best"  cdr) 

("Append"  append) 

) 

This  association  list  binds  the  Omega  names  to  the  appro¬ 
priate  LISP  symbols. 
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and  additional  cycles  will  not  produce  any  new  state 
informa  tion. 

F.  ERROR  COHDITIOHS 

Binding  requirements  differ  as  rule  evaluation  proceeds 
from  the  antecedent  instructions  of  the  rule  to  the  conseq¬ 
uent  instructions.  These  requirements  constitute  a  signifi¬ 
cant  source  of  error. 

In  the  antecedent,  the  members  of  a  tuple  may  or  may  not 
be  bound.  An  unbound  variable  at  this  point  is  not  an 
error,  unless  the  variable  is  involved  in  an  applicative 
expression.  In  the  consequent  cf  a  rule,  all  variables  must 
be  bound.  Unbound  variables  at  this  point  are  reported  as 
an  error. 

The  binding  for  relation  names  is  more  strict.  Given  a 
left-to-right  evaluation  of  instructions,  each  relation  name 
must  be  bound  before  its  evaluation. 

Consider  the  rule: 

» 

if  *R(x),  x  (y,  E)  ->  .  .  . 

The  evaluation  of  relation  R  occurs  first.  The  variable  B 
must  be  globally  bound,  or  an  error  will  occur.  In 
contrast,  the  variable  x  is  bound  in  the  R  (x)  inquiry.  Its 
later  use  as  a  relation  name  is  valid. 

The  requirement  that  relation  names  be  bound  is  an 
implementation  restriction.  A  more  general  mechanism  would 
allow  a  sequential  search  of  all  relations  in  the  database 
for  trial  bindings  of  relation  names.  This  would  extend  the 
free  variable  binding  process  previously  shown  only  for  the 
tuples  in  a  relation. 

A  simple  error-handling  approach  is  used  in  this  system, 
fihen  an  error  is  detected,  a  message  is  displayed  and  the 
interpreter  continues  with  the  evaluation  of  the  next 
instruction. 


Consider  the  following  rule: 


if  *E  1  (x,  x,  y)  ->  B2(x,  y). 

Assume  the  relation  B1  only  contains  the  tuple  <1,  2,  3> . 

Using  the  match  algorithm  previously  described,  the  pattern 
<x,  x,  y>  would  successfully  match  against  <1,  2,  3>.  To 

prevent  such  an  error,  the  match  algorithm  must  take  tempo¬ 
rary  bindings  into  consideration.  This  reguires  an  exposure 
of  some  of  the  details  of  the  binding  mechanism  to  the  rela¬ 
tion  management  routines. 

E.  CCHTEOL 

Active  rule  interpretation  occurs  during  the  sweep  phase 
of  the  interpreter's  top  level.  This  prototype  uses  the 
simplest  possible  control  strategy  for  rule  selection:  each 
active  rule  is  tested  on  every  cycle.  Active  rules  are 
maintained  in  a  list,  and  the  execution  function  is  mapped 
to  each  of  the  rules.  In  LISP  terms,  this  is  written: 

(mapcar  '  (lambda  (rule) 

(exec  (car  rule)  (cadr  rule))) 
ActiveEuleList) ) 

The  lambda  function  splits  each  active  rule  into  its 
instruction  and  environment  components. 

After  each  cycle,  the  above  seguence  returns  a  list  of 
results  from  each  application  of  the  execution  function. 
The  result  for  a  cycle  appears  as: 

(t  t  nil  nil  t  nil  .  .  .nil) 

where  each  "t"  response  comes  from  a  successful  rule  execu¬ 
tion.  The  sweep  phase  will  continue  to  cycle  through  the 
active  rule  list  until  all  rules  return  a  "nil”  response. 
At  this  point,  the  active  rule  list  is  in  a  quiescent  state. 
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directory  to  be  used  for  variable  lookups.  A  rule,  then,  is 
represented  as  a  pair:  <ep,  ip>,  with  environment  pointer 
(ep)  and  an  instruction  pointer  (ip)  .  This  representation 
is  called  a  closure,  and  is  a  technique  used  to  simulate 
static  variable  binding  in  LISP  systems  [Ref.  19:  pp. 
436-37]. 

To  support  temporary  bindings  made  by  pattern¬ 
matching,  a  local  symbol  table  is  used.  The  evaluation  of 
variable  bindings  follows  the  following  sequence: 

•  When  a  rule  begins  execution,  a  global  environment 
pointer  is  set  to  the  environment  pointer  for  the  rule. 

•  To  evaluate  a  variable,  the  local  symbol  table  is 
searched  for  a  previous  definition.  If  not  already 
defined,  the  directory  referenced  by  the  environment 
pointer  is  searched  for  a  global  binding.  If  globally 
bound,  the  variable  and  its  definition  are  installed  in 
the  local  symbol  table. 

•  If  not  defined  in  the  local  symbol  table  or  in  the 
rule’s  directory,  the  variable  is  considered  unbound. 
This  is  represented  by  the  installation  of  a  special 
"unbound"  definition  in  the  local  symbol  table. 

Variable  binding  details  are  external  to  the  rela¬ 
tion  management  functions.  Before  passing  a  tuple  to  the 
match  function,  lookups  are  made  in  the  local  symbol  table 
and  variables  replaced  by  their  definitions.  The  match 
function  accepts  this  tuple  as  input,  and  returns  a  pointer 
to  the  corresponding  relation  tuple  if  a  match  is  found, 
free  variables  become  bound  by  having  their  match  counter¬ 
parts  added  as  definitions  in  the  local  symbol  table. 

The  isolation  of  the  relation  match  function  from 
variable  binding  simplifies  the  interface  between  the  rela¬ 
tion  management  routines  and  the  evaluation  function.  This 
simplistic  approach  is  flawed,  however. 
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match_egual,  however,  no  variable  binding  is  done.  Instead, 
variable  bindings  are  made  after  match_equal  returns  its 
result. 


The  add  function  places  new  tuples  at  the  beginning 
of  the  relation  list,  making  the  relation  list  a  LIFO  struc¬ 
ture.  The  delete  function  removes  a  tuple  directly  from  the 
relation  list. 

5 .  Binding 

Variable  binding  is  controlled  by  symbol  tables  for 
temporary  and  global  bindings.  These  symbol  tables  are 
implemented  as  association  lists,  and  are  manipulated 
through  the  following  management  routines: 

•  Add.  Install  a  symbol  and  its  definition  in  the  symbol 
table. 

•  Delete.  Remove  a  symbol  and  its  definition. 

•  Lookup.  Given  a  symbol,  search  the  table  and  return  the 
definition. 

The  use  of  association  lists  for  symbol  table  repre¬ 
sentation  is  not  the  most  efficient  method  provided  by  LISP, 
but  dees  offer  some  advantages.  The  representation  is 
simple,  and  the  table  contents  can  be  easily  inspected 
during  debugging.  Also,  there  is  a  close  correspondence 
between  these  association  lists  and  the  structure  chosen  for 
relations. 

The  correspondence  between  symbol  tables  and  rela¬ 
tions  allows  the  direct  implementation  of  directories  as 
relations.  The  directory  provides  an  environment  which 
binds  variables  during  rule  evaluation. 

To  support  the  use  of  multiple  directories,  the  rule 
structure  was  expanded  to  include  an  environment  pointer  for 
each  rule.  This  environment  pointer  represents  the 
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if  match_e^ual[  f  irst[  R],  Tuple] 
return  R 

else  R  :  =  rest[  R  ] 
end  while 
return  FALSE 
end  match 

The  match_equal  function  is  a  modified  version  of  a  recur¬ 
sive  list  equality  test-  A  modification  is  required  for 
unbound  variables.  The  algorithm  is: 

match_equal[ R 1 ,  R2 ]  : 

if  R 1=Nil  and  R2=Nil 
return  TRUE 

else  if  R 1 =Nil  or  R2  =  Nil 
return  FALSE 
else  if  R1  is  UNBOUIO 
return  TRUE 
else  if  R1  is  an  atom 
return  R1=R 2 

else  if  match_equal[  f  irst[  El  ],  firsts  R2]] 

return  match_equal[ rest[  R 1 ] ,  rest[R2]] 


else 


return  FALSE. 


end  match_equal. 

The  match  function  performs  a  linear  search  of  the 
relation.  Each  tuple  is  selected  and  tested  until  a  match 
is  found  or  the  list  of  tuples  is  expended.  The  index 
parameter  passed  to  the  match  function  indicates  the  point 
in  the  relation  where  the  search  is  to  begin.  This  indi¬ 
cator  is  non-nil  when  the  match  is  being  requested  on  a 
backtrack  attempt. 

The  match_equal  algorithm  is  similar  to  the  pattern¬ 
matching  algorithm  discussed  in  the  previous  chapter.  In 


h .  Relations 

Relations  are  represented  as  objects  which  have  an 
associated  list  of  tuples.  The  relation  object  identi¬ 

fiers  are  created  through  the  gensym  mechanism  previously 
described.  A  value  is  bound  to  the  symbol  using  the  set 
function  of  LISP. 

To  illustrate  this  representation,  consider  the 
following  sequence  of  command  rules: 

Define  (root,  ”R1M,  Newrel[  ])  . 

R1  ("a",  "b",  »c"). 

R2("x",  "y",  "z"). 

The  Newrel[  J  function  returns  the  object  identifier  for  the 
new  relation.  After  the  assertions,  the  relation  31 
consists  of  the  following: 

( 

("a"  "b"  ” c ") 

llyll  ttzUj 

) 

The  relation  is  a  list  of  tuples,  each  of  which  is  a  list. 

With  the  list  representation  for  relations  is  a  set 
of  management  routines.  These  routines  are  match,  add,  and 
delete. 

The  match  function  provides  the  mechanism  for 
pattern-matched  inquiries.  The  function  is  constructed  as 
follows : 

match[ RelationName,  Tuple,  Index]  : 

if  Index  =  Nil 

R  :=  get  binding  of  Relation  Name. 

else 

R  :=  Index 

endif 

while  R  <>  Nil 


This  applicative  mechanism  bypasses  some  important 
issues  which  a  non-LISP  implementation  must  consider.  These 
issues  include  function  definition  at  the  rule  level  and  the 
interface  between  the  object-oriented  and  applicative  inter¬ 
preter  mechanisms. 

The  simplicity  with  which  new  functions  can  be 
defined  to  support  the  Omega  interpreter  gives  this  imple¬ 
mentation  a  strong  reliance  on  functions.  Consider  the 
implementation  of  a  rule  for  Display: 

if  *Display  (x)  -> 

Null (Print[ x ] )  . 

The  function  call  Print[x]  is  translated  directly  to  the 
IIS?  print  function.  Null  is  a  dummy  relation  whose  only 
purpose  is  to  allow  the  print  function  to  execute. 

In  the  above  example,  the  use  of  the  Print  function 
is  inconsistent  with  the  philosophy  behind  the  applicative 
component  of  Omega.  The  LISP  print  results  in  a  side 
effect,  and  is  therefore  not  a  pure  applicative  expression. 

The  print  mechanism  is  more  accurately  modeled 
through  relations.  A  functional  implementation  is  forced  in 
situations  such  as  this  to  allow  access  to  LISP  definitions. 
The  consequence  of  this  "bending"  of  the  semantics  of  the 
language  is  shown  by  the  appearance  of  awkward  constructs 
such  as  the  Null  relation. 


3 .  Objects 

An  object  in  Omega  is  used  as  a  place-holder  in 
relations.  To  fill  this  role,  the  fundamental  character¬ 
istic  of  objects  is  uniqueness.  This  was  easily  implemented 
usinq  the  gensya  function  of  Franz  LISP  [Ref.  20:  p.  2.8], 
which  returns  a  unique  symbol  each  time  it  is  called.  A 
function  to  create  new  object  identifiers  needs  only  to  make 
successive  calls  to  gensya. 


predecessor  are  popped  from  the  binding  history  list  and 
undone.  If  an  instruction  succeeds,  any  free  variable  bind¬ 
ings  made  during  its  evaluation  are  pushed  on  the  binding 
history  list. 

The  cancel  operation  requires  the  generation  of  a  DEI.2TE 
instruction  should  the  cancel  evaluate  as  "true."  A  delete 
list  is  maintained  for  this  purpose.  To  support  back¬ 
tracking,  the  delete  list  is  checked  for  duplicates  before 
adding  instructions.  The  instructions  in  the  delete  list 
are  passed  to  the  evaluation  function  after  all  the  instruc¬ 
tions  for  the  rule  have  successfully  executed. 

1 .  Instruction  Evaluation 

The  instruction  evaluation  function  performs  a 
direct  interpretation  of  the  instructions  produced  by  the 
parser.  The  steps  of  the  function  are  simple: 

Eval[  1  ]: 

return  Op  [  Eval[  ol,  o2,  .  .  . ,  on  ]  ] 
where  Op  is  the  operator  of  1  and 
<o1,  .  .  . ,  on>  are  the  operands  of  1 

end  Eval. 

The  function  recursively  evaluates  the  operands  of  an 
instruction,  then  applies  the  instruction's  operator  to  the 
result.  To  support  this  organization,  a  LISP  function  is 
defined  for  each  operator. 

2 .  The  Applicative  Component 

The  applicative  component  of  Omega  is  simply 
supported  by  function  definitions  in  LISP.  Such  functions 
are  invoked  by  the  API  operator,  which  is  passed  the  func¬ 
tion  name  and  its  argument".  These  symbols  are  directly 
interpreted  by  LISP,  and  a  result  produced. 


This  problem  is  solved  by  a  pre-scan  of  the  token 
list  before  parsing.  If  the  token  list  doesn’t  contain  the 
tokeii/  it  is  inserted  at  the  beginning  of  the  list. 

D.  SOLE  EVALUATION 

The  interpretation  of  a  rule  is  done  by  an  iterative 
execution  function  and  a  subordinate  recursive  evaluation 
function.  The  execution  function  steps  through  the  instruc¬ 
tions  in  a  rule  and  passes  them  to  the  evaluation  function. 
This  separation  into  iterative  and  recursive  functions  is 
done  to  facilitate  backtracking. 

The  evaluation  function  returns  a  value  of  "true"  or 


"false."  If  an  instruction  is  evaluated  "false,"  the  execu¬ 
tion  routine  resets  any  temporary  bindings  associated  with 
that  instruction's  predecessor,  then  attempts  to  re-execute 
the  predecessor.  The  rule  fails  when  this  process  backs  up 
to  the  initial  instruction.  It  succeeds  if  all  instructions 
succeed. 

At  the  level  of  the  execution  function,  there  is  no 
distinction  between  the  conditions  of  the  antecedent  and  the 
actions  of  the  conseguent.  Backtracking  is  only  meaningful, 
however,  in  the  antecedent  portion  of  the  rule.  Therefore, 
the  evaluation  function  always  returns  "true"  for  instruc¬ 
tions  generated  from  the  conseguent  of  a  rule  unless  an 
error  is  detected. 

An  instruction  history  list  (a  stack)  is  maintained  to 
support  backtracking.  If  a  backtrack  is  reguired,  the 
pointer  to  the  predecessor  instruction  is  popped  from  this 
list.  If  the  instruction  succeeds,  the  pointer  for  the 
instruction  is  pushed  on  the  list. 

A  binding  history  list  (another  stack)  records  the 
logical  variable  bindings  being  made  as  each  instruction  is 
evaluated.  If  an  instruction  fails,  the  bindings  of  its 
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( 

(CANCEL  (INQUIRY  (VAR  »R1")  (TUPLE  (VAR  "X")  ) )  ) 
(PRESENT  (INQUIRY  (VAR  "R2")  (TUPLE  (VAR  "x")))) 
(ASSERT  (VAR  "H3  *• )  (TUPLE  (VAR  "x"))) 

) 

The  sublists  preceded  with  the  symbols  CANCEL,  PRESENT,  and 
ASSERT  are  termed  instructions.  A  list  of  these  instruc¬ 
tions  is  produced  for  every  rule. 

These  instructions  correspond  to  the  basic  actions 
that  the  interpreter  must  perform.  Besides  the  three 
instructions  shown,  this  prototype  produces  similar  instruc¬ 
tions  for  the  deny  operation  (DENY)  . 

Subordinate  instructions  are  created  for  operand 
generation  and  evaluation.  In  the  preceding  example,  the 
sublists  headed  by  INQUIRY,  TUPLE  and  VAR  fall  into  this 
category.  Other  subordinate  instructions  are  included  for 
constants  (CON)  ,  rule  denotations  (DENO)  ,  and  function 
application  (APL). 

A  subset  of  the  original  Omega  grammar  is  recognized 
by  the  parser.  The  intent  was  to  allow  the  interpreter  to 
evaluate  the  simplest  canonical  form  of  rules,  which  uses 
present/inguiry  tests,  absence  tests,  assertions  and 
denials. 

The  Omega  grammar  described  in  [Ref.  14]  makes  no 
syntactic  distinction  between  the  antecedent  and  conseguent 
of  a  rule.  Thus,  a  rule  would  be  written: 

R1  (X)  ,  R2  (x)  ->  R3  (x)  ,  R4  (x)  . 

The  convention  of  allowing  the  "->"  to  be  omitted  in  a 
command  rule  requires  an  indeterminate  lookahead  to  decide 
whether  the  antecedent  or  conseguent  portion  of  the  rule  is 
being  parsed.  If  the  is  omitted,  every  token  in  the 
input  list  must  be  examined. 


40 


T 


V.  A  FOLLOW-ON  IMPLEMENTATION  IN  C 


A.  WHY  C? 

The  second  prototype  was  written  using  the  C  language, 
although  other  alternatives  were  available.  The  decision  to 
to  use  C  was  based  on  the  following: 

•  High  level  control  structures.  The  language  has  a 
reasonable  set  of  control  structures  that  support 
modular  programming. 

•  Simple  but  flexible  data  structuring.  C  supports  a 
limited  but  flexible  set  of  data  types  and  constructors 
that  are  well-suited  for  interpreter  implementations. 
The  bit-level  operations  and  weak  data  typing  provide 
opportunities  for  space  and  speed  optimizations. 

•  Recursion.  C  is  a  recursive  language,  and  many  of  the 

1 

I  algorithms  explored  in  the  LISP  prototype  were  easily 

trans]  ted  into  recursive  C  versions. 

•  Integration  with  UNIX.  As  with  the  LISP  prototype,  the 

j  follow-on  was  developed  on  a  VAX-11/780,  using  Berkeley 

UNIX  (BSD  4.2).  No  language  is  better  suited  to  UNIX 
than  C,  and  vice  versa.  The  operating  system  provides 
many  features  that  directly  support  access  to  system 
routines  and  variables.  The  numerous  software  develop¬ 
ment  tools  available  on  a  UNIX  system  are  largely 
intended  for  use  by  C  programmers. 

C  is  not  a  perfect  implementation  language  by  any  means. 
The  availability  of  low-level  operations  and  type  coercion 
provide  a  dangerous  source  of  error  and  confusion.  The 
terse  syntax  is  difficult  to  read  for  those  unfamiliar  with 
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the  language.  Finally,  C’s  strict  use  of  call-Ly-  ilue 
forces  a  proliferation  of  pointer  usage,  complete  with  a 
flood  ox  subtle  errors  resulting  from  pointer  abuse. 

Despite  its  limitations,  C  is  a  tool  well-suited  to  its 
environment. 

B.  CHANGES  TO  SYNTAI  AND  SEMANTICS 

1 .  An  Antecedent  Keyword 

The  previous  chapter  discussed  the  problem  caused  by 
the  optional  sign  in  the  Onega  syntax.  The  problem  was 

circumvented  in  this  implementation  by  the  use  of  the 
keyword  "if”  to  signify  the  beginning  of  the  antecedent  of  a 
rule.  A  one  token  lookahead  is  sufficient  to  detect  this. 

The  original  Omega  syntax  uses  the  "if"  keyword  to 
signify  a  constraint.  Thus  a  rule  would  be  written: 

*R1  (x)  ,  *R2  (y)  ,  if  x  >  y  ->  .  .  . 

Syntactically,  the  keyword  is  net  necessary  to  distinguish  a 
constraint.  Therefore,  the  use  of  the  keyword  was  modified 
to  solve  the  lookahead  problem.  Using  this  modif ica tion, 
the  rule  is  written: 

if  *R  1  (x)  ,  *R2(y),  x  >  y  .  .  . 

The  semantics  are  unchanged. 

2 •  Rule  Denota  tiens 

The  delimiters  for  a  rule  denotation  were  originally 
asymmetric  quotes.  This  was  modified  to  the  «.  .  •>> 

construct  shown  in  previous  chapters.  This  syntax  was 
selected  to  add  greater  visual  emphasis  for  rule 
denotations. 


3. 


Rule  Separators 

A  small  but  important  modif ication  was  made  to  the 
use  of  the  period  and  comma  as  delimiters.  llacLennan  uses 
the  semi-colon  to  separate  rules  within  a  sequential  block, 
and  a  period  is  used  for  the  separation  of  rules  in  a  deno¬ 
tation.  This  distinction  is  made  to  emphasize  the  sequen¬ 
tial  nature  of  the  block  in  comparison  to  the  concurrent 
nature  of  the  rules  within  the  rule  denotation  [  Eef .  14:  p. 
23]. 

This  distinction  was  altered  to  solve  the  command 
rule  termination  problem.  Rules  are  always  separated  by 
semicolons;  a  period  indicates  the  end  of  the  current 
command  rule  input.  This  replaces  the  dual  carriage  return 
termination  of  the  earlier  prototype. 

This  problem  results  from  the  use  of  rules  as  a 
command  language.  Rules  tend  to  span  multiple  lines,  so  a 
simple  end-of-line  termination  is  not  sufficient  to  indicate 
the  end  of  input.  Two  alternative  solutions  to  this  problem 
are:  (1)  terminate  a  multi-line  command  with  a  continuation 
character,  or  (2)  use  a  special  character  to  signify  the  end 
of  input. 

The  latter  technique  was  selected,  with  some  loss  of 
the  useful  syntactic  distinction  between  denotations  and 
sequential  blocks.  It  is  hoped  that  the  remaining  distinc¬ 
tions  between  the  two  constructs,  <<>>'s  vs.  {}  *s,  are 
sufficiently  different  to  serve  as  a  reminder  of  the  differ¬ 
ences  in  semantics. 

4 .  Parameter  Lists 

The  original  syntax  for  a  function  call  was  similar 
to  the  form  of  an  assertion  or  an  inquiry.  Thus  a  rule 
would  appear  as: 

*R1  (x,  y)  ->  R2{cons(x,  y)). 
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The  square  bracket  notation  for  function  parameter  lists  was 
selected  to  provide  an  obvious  distinction  between  function 
calls  and  other  non-applicative  forms  in  the  language.  The 
square  brackets  also  denote  lists,  with  the  similarity 
emphasizing  the  semantic  connection  between  these 
cons  tructs. 

A  similar  modification  was  made  for  the  procedure 
call,  where  curly  braces  denote  the  parameter  lists.  This 
syntax  appears  unusual,  and  the  procedure  call  mechanism  is 
unusual.  The  semantic  similarities  between  the  procedure 
call  and  the  sequential  block,  both  of  which  provide  some 
degree  of  control  on  the  otherwise  free  concurrency  of 
Omega,  is  emphasized  by  their  common  use  of  curly  braces. 

5 .  Conditional  Expressions  and  Function  Definitions 

The  introduction  of  an  applicative  component  into 
the  language  required  syntactic  extensions.  These  exten¬ 
sions  were  centered  around  the  conditional  expression,  which 
is  illustrated  by  the  following  rule: 

if  *Rl(x)  ->  R2  (  if  x<3  ->  "YES"  else  "NO"  ). 

The  value  of  the  assertion  is  determined  by  the  conditional 
expression. 

Given  the  form  of  the  conditional  expression,  a 
function  declaration  can  be  formed  by  giving  the  function 
name,  parameter  list,  and  body  (a  conditional  expression)  : 

fn  Max[ x,  y]  :  if  x  >  y  ->  x  else  y. 

Syntactically,  a  function  declaration  may  appear  anywhere  a 
command  rule  would  appear. 

The  form  of  the  conditional  expression  is  a  modifi¬ 
cation  to  the  original  syntax  of  the  rule,  with  restrictions 
to  prevent  side  effects. 
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6 .  An  Implicit  Response  for  Command  Rules 

A  syntactic  change  was  made  to  allow  expressions  at 
the  same  level  as  assertions.  This  modification  allows  the 
entry  of  the  following  command  rule: 

if  *R  1  (x)  ->  x. 

When  this  rule  is  evaluated,  t be  binding  of  x  is  "returned" 
by  the  rule.  If  this  binding  is  printed  by  the  interpreter, 
the  necessity  for  ubiquitous  "Eisplay"  calls  may  be  less¬ 
ened.  This  allows  the  command  entry  of  expressions  such  as: 

2  +  2  *  Sin[  Pi/2  ]. 

where  the  interpreter  returns  the  result. 

While  this  modification  to  the  rule  syntax  is 
convenient  for  command  rules,  it  provides  some  interesting 
semantic  questions.  Suppose  the  following  is  an  active 
rule: 

if  *R  1  (x)  ->  2  ♦  2. 

What  does  the  consequent  of  this  rule  mean?  It  involves  no 
alteration  of  the  database,  but  instead  requires  an  expres¬ 
sion  evaluation. 

The  action  may  be  described  by  the  following  equiva¬ 
lent  form: 

if  *H1  (x)  ->  Eval  {" 2  ♦  2"}. 

The  expression  is  asserted  to  an  implicit  Eval  relation,  and 
the  semantics  of  the  procedure  call  apply.  Note  that,  in 
general,  the  value  returned  by  a  procedure  call  used  at  this 
level  is  ignored.  For  command  rules,  this  value  may  be  used 
to  indicate  the  result  returned  from  evaluating  a  rule. 

Given  this  interpretation,  consider  the  following 

rule : 

if  *R1  (x)  ->  R2  (x)  . 
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What  is  the  "result"  returned  ty  the  assertion?  A  simple 
convention  is  that  that  the  assertion  of  a  tuple  x  to  a 
relation  R  returns  the  tuple  x  as  its  result. 

7.  Head/Tail  Pattern  Speci fica tions 

A  final  added  feature  is  a  head/tail  pattern  speci¬ 
fication  for  lists,  similar  to  that  of  Prolog  [  Bef-  21:  p. 
43].  This  is  shown  in  the  following  rule: 

if  *Rl([h:t])  - >  R 1  (h)  ,  R2(t). 

The  [h:t]  notation  will  match  a  list.  The  variable  h  will 
be  bound  to  the  head  (first)  of  the  list,  the  variable  t 
will  be  bound  to  the  tail  (rest)  of  the  list. 

The  head/tail  specification  syntax  is  extended  for 

tuples: 

if  *R1  (h:  t)  ->  R 1  (h)  ,  R2(t). 

This  notation  provides  a  pattern  specification  for  tuples 
that  is  independent  of  tuple  cardinality.  This  generality 
was  not  possible  using  previous  constructs. 

C.  DATA  STRUCTOHES 

Data  structures  posed  the  major  design  challenges  for 
this  interpreter.  The  structures  of  particular  interest 
were  the  representa tions  for  rules  and  for  supporting  the 
objects  and  values  of  the  language. 

1 .  A  Uniform,  Tagged  List  Structure 

A  list  structure,  similar  to  that  of  LISP,  was  selected  for 
the  representation  of  rules.  This  structure  was  selected 
for  the  following  reasons: 
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•  Rules  are  represented  as  binary  trees.  Using  a  list 
structure  for  rules  allows  a  direct,  recursive  evalua¬ 
tion  technique  similar  to  that  of  the  LISP  prototype. 

•  Omega  needs  lists.  Lists  provide  a  general  constructor 
mechanism  that  is  extremely  flexible.  In  a  pattern¬ 
matching  language,  list  structures  are  essential  if 
pattern-matching  is  to  extend  beyond  character  strings. 

•  Uniform  list  structures  simplify  design.  Given  that 

lists  are  desirable  as  a  data  type  within  the  language, 
a  simple  set  of  list  handling  routines  suffices  for 
analysis  and  synthesis  of  data  within  the  interpreter. 
Uniform  list  structure  also  allows  storage  allocation 
and  reclamation  to  concentrate  on  a  single  unit:  the 

list  cell. 

A  diagram  ox  the  basic  cell  structure  is  shown  in 
Figure  5.1  The  cell  has  three  fields:  a  tag  field,  a  head 

field,  and  a  tail  field.  Table  I  shows  the  types  of  values 
that  each  field  may  assume. 

The  atomic  values  in  this  implementation  are  char¬ 
acter  strings,  signed  integers,  and  objects.  These  atoms 
are  represented  by  cells.  The  type  of  an  atom,  as  with  all 
cells,  is  determined  by  the  value  of  its  tag  field. 

Integers  have  their  values  contained  directly  in  the 
head  field  of  a  cell.  Likewise,  objects  have  their  identi¬ 
fiers  encoded  in  this  field.  The  width  of  this  field  is  32 
bits,  determined  by  the  VAX  11/780  word  size. 

Character  strings  have  a  pointer  in  the  head  field 
that  references  a  contiguous  block  of  string  storage. 
Reflecting  their  C  implementation,  string  storage  areas  are 
NULL  terminated.  On  the  VAX,  NULL  is  represented  by  a  zero 
value. 
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Figure  5. 1  Cell  Structure. 


A  list  cell  contains  pointers  ir.  both  the  head  and 
tail  fields.  There  are  two  classes  or  list  cells:  data 
list  cells  and  operator  list  cells.  These  are  distinguished 
by  tag  values. 

Data  list  cells  are  analogous  to  LIS?  lists.  They 
serve  as  data  constructors.  Operator  list  cells  form  the 
interior  nodes  of  a  binary  tree  representation  for  rules. 
Rules  are  transformed  and  evaluated  as  tree  structures.  The 
"instruction”  concept  of  the  prototype  was  dropped  in  favor 
of  a  more  uniform  approach.  Figure  5.2  illustrates  the 
parse  tree  for  a  simple  arithmetic  expression. 

This  tagged  structure  simplifies  evaluation  at  the 
expense  of  storage  space.  Individual  tags  are  used  for  all 


TABLE  I 

Cell  Field  Values 


head  field: 
Contents 


cell  pointer 
string  pointer 
integer 

object  id 
<blcck, of£set> 


tail  field: 
Contents 


cell  pointer 


unused 


Comments 


data  and  operator  list  cells 
string  cell 
integer  cell  value 

used  for  frame  size  in  allocate  op 
object  cell — id  is  32  bit  integer 
VAfi  cell — gives  scope  and  offset 


within  binding  stack  frame 


Comments 


data  and  operator  list  cells 

VAR  cells  and  defined  objects  have 

pointers  to  print  names 


integer,  string, 
and  most  object 


cells 


primitive  data  types  and  for  each  construct  (node)  in  the 
abstract  syntax  for  rules.  This  results  in  a  large  number 
of  tags:  over  4 0  in  the  current  implementation.  A  minimum 
of  6  bits,  therefore,  is  required  to  represent  the  tag  of  a 
node.  Given  the  cell  space  reguirements  given  in  Figure 
5.1,  approximately  11  percent  of  the  system  storage  reguire- 
ment  is  needed  for  tags.  (The  actual  percentage  is  somewhat 
less  because  of  character  string  blocks  and  hash  tables, 
discussed  below)  . 

2 .  Objects 

As  in  the  LISF  prototype,  objects  are  represented  by 
a  unigue  identifier.  In  this  implementation  a  cell  is 
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Expre.  si  on :  2  + 


5 


Figure  5.2  Tree  Bepresentatica  for  a  Simple  Expression. 

generated  for  an  object  and  ar  identifier  embedded  in  the 
head  field.  Again  the  problem  is  how  to  manage  the  identi¬ 
fiers  so  that  the  are  unique. 

The  approach  used  is  tc  maintain  an  object  count. 
Each  time  a  new  object  is  reguested,  the  object  count  is 
incremented.  If  the  control  of  object  identifier  allocation 
remains  centralized,  the  objects  are  guaranteed  tc  be 
uni gue. 

The  generation  of  identifiers  this  way  leads  to  the 
issue  of  object  identifier  management.  What  prevents  the 
system  from  running  out  or  unique  identifiers?  What  happens 
when  the  identifier  space  is  exhausted? 


A  simple  strategy  is  to  ignore  these  problems  alto¬ 
gether.  How  long  can  the  system  generate  identifiers  before 
it  runs  out?  For  a  rough  calculation,  assume  that  a  new 
identifier  is  generated  every  10  milliseconds.  The  head 
field  which  contains  an  identifier  is  32  bits,  so  assume  29 
bits  are  available  (the  use  fcr  the  remaining  3  bits  will 
be  discussed  shortly).  With  these  values,  the  identifier 
space  would  be  exhausted  in  22 9  x  10  milliseconds,  or  about 
62  days.  The  management  of  object  identifiers  is  not  a 
major  issue  in  this  system.  Should  a  larger  object  identi¬ 
fier  space  be  needed,  additional  bits  could  be  provided  from 
the  tail  field  of  the  object  cell. 

A  small  portion  of  the  object  identifier  space  is 
reserved  for  system  use.  In  the  current  implementation, 
the  first  64  object  identifiers  are  reserved.  The  presence 
of  a  system  object  is  easily  detected  by  an  examination  of 
its  identifier. 

3 .  Hash  Tables 

As  in  the  LISE  prototype,  certain  types  of  objects 
have  values  associated  with  them.  These  values  are  managed 
in  this  implementation  using  a  uniform  hash  table  mechanism. 

The  hash  table  index  is  generated  by  a  simple  hash 
function.  The  algorithm  is  based  on  that  given  in  [Ref.  22: 
p.  135].  The  hash  function  receives  a  pointer  to  a  cell  as 
an  argument,  and  returns  the  table  index.  The  algorithm  is 
as  follows: 

hash[  p  ]  : 

if  pa  is  an  integer  or  object  cell 
return  pahead  mod  TABLESIZE 
else  if  pS  is  a  string  cell 

return  sum[p3head]  mod  TABLESIZE 

where  sua[  s  ]  returns  the  sum  of 

the  ASCII  characters  in  the 
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else 


string  s 


return  0 

endif 
end  hash. 

This  function  is  a  crude  hashing  algorithm  for  string 
entries,  with  its  primary  virtue  being  simplicity.  Object 
identifiers  are  generated  linearly,  however.  The  direct 
hash  off  these  identifiers  should  result  in  minimal 
collisions. 

The  structure  itself  consists  of  a  pointer  table  (an 
array),  with  a  collision  list  maintained  for  each  entry. 
The  collision  list  links  together  a  collection  of  header 
cells.  These  cells  have  a  key  field  with  a  list  cell 
pointer,  a  definition  field  with  another  list  cell  pointer, 
and  a  link  field  with  a  pointer  to  the  next  header  ceil. 
Figure  5.3  illustrates  this  structure. 

To  complete  the  hash  table  description,  a  collection 
of  management  and  access  routines  are  used.  These  are: 

•  lookup.  Given  a  pointer  tc  a  cell,  find  an  entry  whose 
key  field  points  to  an  equivalent  structure.  If  found, 
return  the  definition  pointer. 

•  Install.  Add  an  entry  to  the  hash  table.  The  hash 

table  is  searched  for  an  existing  entry  with  the  same 
key  value.  If  found,  that  entry  is  replaced.  If  not 
found,  the  new  entry  is  linked  into  the  appropriate 
collision  list.  Note  that  key  entries  may  be  any  struc¬ 
ture:  objects,  strings,  or  lists. 

•  Delete.  Remove  an  entry  from  the  table.  The  table  is 
searched  for  the  key  value.  If  found,  the  entry  is 
removed  and  its  collision  list  is  relinked  if  necessary. 
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Figure  5.3  Hash  Table  Structure. 

Object  representations  are  linked  to  object  identi¬ 
fiers  using  these  hash  tables.  The  objects  within  C mega 
that  have  representations  are  relations,  directories,  rule 
denotations,  and  functions.  These  entities  are  subject  to 
temporal  change,  and  thus  have  an  object  implementation. 
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4 .  gelations 

Relations  are  objects,  tut  with  a  twist:  they  have 
access  considerations.  The  access  control  mechanism  is 
encoded  directly  into  a  relation’s  object  identifier.  Three 
bits  of  the  identifier  signify  whether  the  relation  is 
accessible  for  read,  add,  or  delete  operations.  When  a  new 
relation  is  created,  an  object  identifier  is  generated  and 
the  capability  bits  all  set  tc  1,  indicating  full  privi¬ 
leges.  Subseguent  operations  may  reduce  the  capability  by 
copying  the  relation  object  identifier  and  zeroing  the 
appropriate  bits.  This  produces  a  second  reference  to  the 
same  relation,  but  with  reduced  access  privileges. 

Relations  are  represented  as  lists,  similar  to  the 
LISP  prototype.  As  a  tuple  is  added  to  a  relation,  a  header 
cell  is  created  for  the  tuple  and  linked  in  at  the  head  of 
the  existing  tuple  list  (if  any).  A  pointer  to  this  list  s 
bound  to  the  relation's  object  identifier  through  the  object 
table.  The  list  representation  of  a  relation  is  shown  in 
Figure  5.4 

5 •  Directories 

Directories  incorporate  the  hash  table  into  the 
general  list  structure.  A  directory  has  two  header  cells: 
a  class  link  cell  and  a  partition  ceil. 

The  class  link  cell  contains  a  pointer  to  a  parti¬ 
tion  cell,  and  a  pointer  to  the  next  class  link  cell  in  the 
class.  A  lookup  path,  then,  may  follow  this  chain  from 
directory  to  directory. 

The  head  pointer  of  the  partition  cell  points  to  the 
private  partition,  while  the  tail  pointer  of  the  cell  points 
to  the  public  partition.  Each  partition  is  represented  by  a 
single  hash  table. 
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lookups  in  the  object  table  where  necessary-  Thus,  the 
philosophical  differences  between  objects  and  values  in 
Omega  are  supported  by  concrete  differences  at  the  implemen¬ 
tation  level. 

I.  BACKTRACKING 

A  recursive  backtracking  algorithm  is  implemented  with  the 
conditions  (CONDS)  operator.  A  condition  is  an  element  of 
the  antecedent  of  a  rule:  a  ^iresence/in jUiry  test,  an 

absence  test,  or  a  constraint.  Backtracking  is  initiated 
only  on  the  failure  of  a  presence  test.  The  algorithm  is: 

conds[ cond_curr  ,  cond_next,  ep  ]  : 
match_next_ptr  :=  Nil 
while  TRUE 

result  :=  eval[ cond_curr ,  ep  ] 
if  result  =  FAIL 
return  FAIL 

else  if  cond_next  =  Nil 
return  result 
end  if 

result  :=  eval[ ccnd_next ,  ep] 
if  result  !=  FAIL 
return  result 

endif 

if  cond_curr  is  not  a  'present'  op 
return  FAIL 
end  i  f 

undo  trial  bindings  made  for  condition 
end  while 
end  conds 

This  algorithm  treats  backtracking  as  a  binary  operation. 
The  "cond_curr"  parameter  is  the  current  condition  being 
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The  binding  process  uses  the  following  primitive 
rout ines : 

•  bind[X/  y  ].  The  frame  slot  for  variable  x  is  assigned 
pointer  y. 

•  getbinding[  x ].  Return  the  value  in  the  frame  slot  for 
variable  x. 

•  freebinding[  x ].  Free  the  binding  for  variable  x.  This 
is  accomplished  by  assigning  a  reserved  value  to  the 
frame  slot  meaning  UNBOUND. 

When  a  rule  completes  execution,  the  dynamic  link  is 
followed  to  the  previous  frame,  and  the  current  frame 
pointer  reset. 

The  binding  stack  offers  several  advantages.  First, 
variable  lookups  are  only  done  once:  at  activation  time. 

The  dynamic  binding  process  is  only  concerned  with  a  vari¬ 
able’s  offset  in  the  stack  frame,  not  with  the  variable 
name.  The  binding  stack  allows  the  simple  reclamation  of 
storage  used  for  binding.  Finally,  it  allows  context 
switching  in  rule  interpretation  since  bindings  from  inter¬ 
rupted  rules  are  preserved. 

A  context  switch  for  a  rule  occurs  during  a  synchro¬ 
nous  call.  Consider  the  following  rule: 

if  *R1  (x)  ->  {  F.2{x};  R3{x}  }. 

When  the  R2  procedure  call  is  made,  a  context  switch  is  made 
to  the  body  of  rules  that  support  the  call.  The  binding  of 
the  variable  x,  however,  must  be  maintained  between  the  H2 
procedure  call  and  the  R3  procedure  call. 

This  method  of  static  binding  eliminates  unnecessary 
variable  lookups  by  replacing  variables  by  their  defini¬ 
tions.  Generality  is  still  maintained  for  objects  such  as 
relations,  whose  associated  values  are  determined  by  dynamic 
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A  variable  not  defined  in  the  directories  of  the 
class  is  a  free  variable.  The  cell  representing  a  free 
variable  contains  an  offset  in  the  head  field,  and  a  pointer 
to  the  variable's  print  name  (a  string  cell)  in  the  tail 
field.  The  offset  for  a  variable  depends  on  the  order  in 
which  the  free  variables  of  a  rule  appear. 

When  a  free  variable  cell  is  initialized,  a  pointer 
to  the  variable  cell  is  installed  as  the  print  name's  defi¬ 
nition  in  a  local  symbol  table.  Subsequent  occurrences  of 
the  variable  will  be  replaced  by  this  definition. 

During  the  binding  process,  the  parse  trees  for 
embedded  rule  denotations  are  installed  in  the  object  table. 
A  system-generated  object  identifier  replaces  the  rule  deno¬ 
tation  subtrees  in  their  parent  expressions.  The  variables 
in  the  rule  denotation  are  left  unbound — the  binding  of 
these  variables  is  deferred  until  the  denotation  is 
activated. 

The  final  action  for  the  binding  process  is  the 
creation  of  an  allocation  operator  cell  for  the  rule.  This 
cell  has  a  count  of  the  total  number  of  free  variables  for 
the  rule  in  its  head  field.  The  tail  field  contains  a 
pointer  to  the  actual  rule  structure. 

2 .  A  Binding  Stack 

The  allocation  operator  is  used  with  a  binding 
stack.  The  binding  stack  is  an  array  with  a  current  frame 
pointer  and  a  chain  of  dynamic  link  pointers  that  connect 
frames.  The  binding  stack  is  illustrated  in  Figure  5.7 

When  a  rule  begins  interpretation,  a  stack  frame  is 
created  on  the  binding  stack  with  slots  allocated  for  each 
free  variable  in  the  rule.  The  offset  in  a  variable  cell 
indicates  which  of  the  binding  frame  slots  is  to  be  used  for 
that  variable. 
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result  :=  rule[ ip3head,  ipStail,  ep] 

end  case 
return  result 
end  eval 

As  in  the  LISP  prototype,  separate  functions  are  defined  for 
the  majority  of  interpreter  actions.  The  function  rule  is 
defined  external  to  the  case  statement,  and  contains  code 
for  the  interpretation  of  the  PULE  operator.  Separate  calls 
to  eval  are  used  to  evaluate  the  arguments  to  rule. 

The  evaluation  function  receives  two  arguments:  a 

pointer  to  the  subtree  being  evaluated  (ip),  and  a  pointer 
to  the  current  directory  for  global  name  definitions  (ep)  . 
The  evaluation  function  returns  a  cell  pointer  as  its 
result. 

fl.  BINDING 

1  *  BifiJifiS  At  Activation 

This  implementation  uses  an  entirely  different 
binding  mechanism  than  the  LISP  prototype.  The  variables  of 
a  rule  denotation  are  bound  when  a  rule  becomes  active. 
These  bindings  are  determined  by  the  environment  of  activa¬ 
tion.  Since  a  command  rule  is  immediately  executed,  binding 
takes  place  immediately  for  these  rules. 

The  binding  process  results  in  a  complete  copy  of 
the  parse  tree  for  a  rule,  leaving  the  original  denotation 
unaltered  for  later  use.  In  this  way,  the  denotation  is 
like  a  source  file,  the  bound  parse  tree  like  an  object 
file . 

When  a  rule  denotation  is  bound,  the  current  direc¬ 
tory  is  searched  for  variable  definitions.  The  class  of  the 
current  directory  provides  a  search  path  to  other  directo¬ 
ries  if  the  variable  is  not  bound  in  the  current  directory. 
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of  the  current  subtree, 
described  as: 


A  section  of  the  algorithm  may  be 


pretty_print[ p  ]  : 

do  case  pStag 

•  •  • 

case  RULE  : 

print£  "if"  ] 
pretty_print[  p3head  ] 
print[  ] 

prett y_print[  p3)tail  ] 
print[ "; " ] 

•  •  • 

end  case 
end  pretty_print 

Although  the  pretty  printer  originated  as  a  debugging 
aid,  the  basic  design  of  the  tag-oriented  case  statement  was 
almost  identical  for  the  central  evaluation  function.  This 
pretty  printer  evolved  into  the  Display  mechanism  for  the 
interpreter. 

G.  ROLE  EVALUATION 

Where  the  LISP  prototype  used  a  separate,  iterative 
execution  function  for  backtracking,  the  follow-on  design 
uses  a  recursive  backtracking  algorithm  within  a  single 
evaluation  function. 

As  in  the  pretty  printer,  the  heart  of  the  evaluation 
function  is  a  large  case  statement.  The  tag  value  of  the 
form  being  evaluated  determines  the  case  selection.  A 
section  of  this  case  statement  may  be  described  as: 

evalfip,  ep  ]  : 

do  case  ip2tag 

m  m  • 

case  RULE: 
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Figure  5.6  Transformed  List  Structure. 


F.  A  BECUBSIVE  PRETTY  PBINTEE 

The  parser,  along  with  the  cell  allocation  routines  to 
generate  the  parse  tree,  was  the  first  system  component 
developed  for  this  implementation.  A  pretty  printer  was 
written  at  this  point  primarily  to  debug  the  parser. 

The  pretty  printer  is  based  on  a  large  case  statement, 
which  selects  the  appropriate  output  form  based  on  the  tag 


T 


List:  [1,  2,  3] 


Figure  5.5  Left-Recursive  List  Representation. 

The  scanner  produced  Li  LEX  accepts  input  from  the 
standard  input  file  by  default.  To  receive  input  from 
another  text  file,  the  file  is  opened  and  the  LEX  input  file 
variable  reassigned.  This  simple  technique  allows  the 
alternation  of  input  between  several  sources. 
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currShead  :=  t; 
currStail  :=  prec 
if  h  =  Nil 

return  curr 

else 

return  h 
end  if 
end  if 
end  rtrans 

Figure  5.6  shows  the  list  after  the  transformation  has  been 
applied . 

The  YACC  parser  offers  several  advantages  to  a 
prototyping  effort: 

•  Development  time.  The  high  level  of  the  specification 
for  YACC  minimizes  the  complexity  of  parser  generation. 
Fe  had  a  complete,  functional  parser  working  in  three 
days . 

•  Ease  of  modification.  Experimentation  with  syntax  is 

simple:  change  the  grammar  rules,  rerun  YACC,  and 

recompile  the  output.  The  ease  with  which  the  grammar 

can  be  modified  encourages  experimentation. 

•  Verifying  specifications.  Analysis  of  grammar  changes 
is  easy  in  YACC.  If  a  change  produces  ambiguities,  YACC 
will  report  conflicts  when  trying  to  generate  the  parser 
tables.  This  automated  analysis  is  a  strong  point  in 
favor  of  using  a  YACC  parser. 

3.  Console  and  File  Input 

As  in  the  LISP  prototype,  the  same  parser  is  used  to 

read  command  rules  from  the  console  and  from  text  files. 

This  is  implemented  using  the  i/o  redirection  facilities  of 
UNIX  and  C. 
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rule  [Eef.  24:  pp.  14-15].  This  scheme  results  in  a  flat 
grammar  for  expressions  in  YACC,  where  the  precedence  rules 
determine  associativity  and  precedence. 

Certain  constructs  in  Omega  lend  themselves  to 
recursive  grammar  rules.  YACC  encourages  such  rules  to  be 
lef t-recursive.  Left-recursive  rules  result  in  a  smaller 
parser  size,  and  reduce  the  likelihood  of  an  internal  stack 
overflow  when  parsing  a  long  seguence  [Hef.  24:  p.  19.]. 

Consider  the  following,  left-recursive  specification 
for  a  list: 

list  :  expression 

]  list  • , '  expression 

The  parse  tree  generated  by  such  a  rule  is  shown  in  Figure 
5.5  Cne  consequence  of  this  fcrm  is  that  the  entire  list 
must  be  traversed  to  access  the  head  of  the  list,  an  obvious 
disadvantage  in  list-oriented  interpretation. 

To  solve  this  problem  while  still  respecting  the 
YACC  preference  for  left-recursion,  a  recursive  transforma¬ 
tion  is  performed  on  parse  trees.  This  transformation 
selectively  changes  left-recursive  forms  into  right- 
recursive  forms.  The  algorithm  is: 

rtrans£curr,  pred]  : 
if  curr  =  Nil 

return  Nil 

else  if  curr  points  tc  an  atom 
return  curr 

else  if  curr  is  not  a  left  recursive  form 
curraJhead  :=  rtrans]  currShead,  Nil  ] 
currStail  :=  rtrans[  curr$tail.  Nil  ] 
return  curr 

else 

h  :=  rtrans[  curr  ahead,  curr] 
t  :=  rtrans[  curratail.  Nil] 
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assertion  :  primary  *('  arguments  ')  ' 

( 

3$  =  newcell  (ASSERT,  31,  33); 

} 

Additional  rules  are  given  for  "primary"  and  "arguments." 
The  newcell  function  generates  a  new  cell  with  the  tag 
ASSERT,  a  head  pointer  set  to  the  value  returned  by  YACC 
from  parsing  "primary,"  and  the  tail  pointer  set  to  the 
value  returned  by  YACC  from  parsing  "arguments." 

The  embedded  C  expression  determines  the  actions  of 
the  parser  if  an  assertion  is  recognized.  The  assignment  to 
"$3"  defines  YACC's  response;  this  value  is  placed  on  a 
stack  for  use  in  other  expressions.  In  this  implementation, 
the  value  generated  for  each  rule  is  a  cell  pointer.  When  a 
form  is  parsed  successfully,  the  YACC  parser  returns  a 
pointer  to  the  root  of  a  parse  tree  constructed  this  way. 
The  YACC  specification  for  Omega  is  contained  in  Appendix  A. 

YACC  is  a  more  complex  tool  than  LEX,  and  it  has 
some  idiosyncrasies.  These  include  precedence  specification 
for  infix  expressions  and  a  preference  for  left- recursive 
grammar  rules. 

Infix  expressions  may  be  specified  in  YACC  ty  a  rule 

such  as: 

expr  ;  expr  OP  expr 

Such  a  specification  is  ambiguous,  however.  To  remove  this 
ambiguity,  YACC  allows  the  declaration  of  precedence  rules. 
Thus  a  precedence  rule  of: 

*left  «-• 

Xieft  '*»  •/' 


would  establish  the  precedence  of  the  arithmetic  operators 
and  resolve  the  ambiguities  associated  witn  the  previous 


that  a  reasonably  efficient  parser  be  produced  with  a 
minimum  of  time  and  effort. 

1 •  h  iSX  Scanner 

The  LEX  lexical  analyzer  generator  [Ref.  23]  was 
used  to  produce  the  code  for  the  scanner.  LEX  accepts  as 
input  a  file  of  rules  described  through  regular  expressions 
and  their  associated  actions.  The  output  from  LEX  is  a 
table-driven  scanner  in  C  source  code. 

The  following  seguence  defines  LEX  actions  for 
recognizing  unsigned  integers: 

digit  [  0-9  ] 
int_con  [digit}  + 

{int_con}  { 

return  (INT_CON)  ; 

} 

The  return  statement  is  an  embedded  C  language  construct 
used  to  describe  the  required  action  by  the  scanner.  In 
this  example,  INT_CCN  is  a  constant  used  to  represent  the 
token . 

LEX  is  an  easy-to-use,  sophisticated  tool.  With  no 
previous  experience,  we  specified,  generated,  compiled,  and 
debugged  a  LEX  scanner  in  a  few  hours.  The  LEX  specifica¬ 
tion  for  Omega  is  contained  in  Appendix  A. 

2 .  A  YACC  Parser 

The  parser  was  written  using  the  YACC  (Yet  Another 
Compiler-Compiler)  parser  generator  [Ref.  24].  Like  LEX, 
YACC  allows  a  high  level  specification  for  compiler  actions. 
The  output  from  YACC  is  a  table-driven,  LALR(1)  parser.  The 
YACC  parser  receives  its  token  input  from  the  LEX  scanner. 

The  following  illustrates  the  YACC  specification  for 
an  Omega  assertion: 
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from  the  notion  that  a  command  rule  "returns"  a  result.  The 
top  level,  then,  consists  of  a  read-evaluate -pri nt- sweep 
loop. 

The  r  ead-evaluate- print  phases  process  the  user's 
command  entry  at  the  terminal.  The  print  phase  provides  a 
visual  indicator  that  some  activity  is  taking  place  because 
of  the  command  rule  entry. 

Suppose  a  user  enters  the  following  rule  at  the 
terminal : 

if  *R1  (x)  ->  R2  (x)  ,  R3  (3)  . 

The  reader  parses  the  expression,  binds  variables  as  appro¬ 
priate,  and  then  passes  the  parse  tree  to  an  evaluation 
function.  The  response  from  the  evaluation  function  is 
displayed  at  the  terminal.  In  this  example,  this  resp  nse 
would  be  "3."  When  multiple  expressions  exist  in  the 
consequent  of  a  rule,  the  response  from  the  last  expression 
is  displayed  as  the  response  for  the  rule. 

After  the  command  rule  has  been  evaluated  and  its 
response  displayed,  the  interpreter  begins  its  sweep  phase, 
evaluating  any  active  rules  that  are  ready  to  fire.  There 
is  no  implicit  response  from  active  rules:  their  purpose  is 
to  alter  the  database.  At  the  completion  of  the  sweep 
phase,  the  command  loop  returns  to  the  reader  and  waits  for 
the  next  entry. 

E.  THE  READER 

The  reader  was  a  major  weakness  in  the  LISP  prototype. 
While  an  efficient  parser  implementation  was  not  a  major 
design  goal  for  this  work,  the  slow,  error-prone  parser  of 
the  LISP  prototype  was  frustrating  to  work  with. 

A  parser  generator  was  used  to  create  the  parser  in  the 
second  prototype.  This  decision  was  made  with  the  intent 
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tested.  The  "cond_next1'  points  to  the  remain 
conditions  to  be  tested.  A  successful  response 
"cond-next"  indicates  that  all  remaining  cond 
tested  successfully.  A  failure  means  a  backt 
should  be  made  on  the  current  condition. 


ing  list  of 
from  eval  on 
itior.s  have 
rack  attempt 


J.  RELATION  MANAGEMENT  ROUTINES 


The  relation 

management  routines 

of 

the 

LISP  prototype 

are 

continued  in 

this  implementation. 

They 

are:  match. 

add. 

and  delete. 

As  in  the  LISP  prototype,  the  add  function 

links  a  new  tuple 

at  the  beginning 

of 

t  he 

relation  list. 

The  delete  function  removes  the  tuple  from  the  relation  list 
and  relinks  as  necessary. 

A  pattern-matching  algorithm  is  used  in  the  relation 
match  function.  As  in  the  LISP  prototype,  the  tuple  list  of 
a  relation  is  searched  linearly.  As  each  tuple  is  selected 
for  a  match,  it  is  passed  to  the  pattern-matching  function. 
The  match  function  maintains  a  "match_next"  pointer.  This 
indicates  where  the  last  match  occurred,  and  provides  a 
search  continuation  point  for  backtracking. 

The  pattern-matching  algorithm  is  similar  to  that  given 
in  Chapter  III.  Unlike  in  the  LISP  prototype,  trial  vari¬ 
able  binding  occurs  during  pattern  matching.  The  pattern¬ 
matching  function  binds  free  variables  by  using  the  bind 
operator  of  the  binding  stack.  These  bindings  are  undone  if 
a  rematch  is  necessary  when  backtracking. 

In  this  implementation,  relation  access  control  is 
enforced.  The  object  identifier  for  the  relation  is  first 
tested  to  ensure  the  capability  bit  for  the  desired  opera¬ 
tion  is  set.  If  not,  the  operation  is  canceled  and  an  error 
message  is  generated. 

An  additional  relation  function  was  added:  match_first. 
This  function  returns  a  pointer  to  the  first  tuple  in  a 
relation. 
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K.  ACTIVE  ROLE  PROCESSING 

1 .  Triggers 

The  technique  of  triggering  is  used  to  improve  the 
precision  of  active  rule  processing.  The  trigger  for  a  rule 
is  the  left-most  relation  in  the  the  rule.  For  the 
following  rule: 

if  *R  1  (x)  /  *R2  (y)  ->  .  .  . 

the  trigger  is  the  relation  R1. 

A  rule  is  selected  for  test  when  certain  events  take 
place  involving  the  trigger  relation.  These  events  are 
assertions  and  deletions.  If  eitner  of  these  operations  is 
performed  on  the  trigger  relation,  there  is  a  likelihood 
that  the  rule’s  antecedent  conditions  are  now  satisfied. 

The  triggering  process  is  initiated  at  the  time  a 
rule  is  activated.  The  trigger  for  a  rule  is  determined, 
and  the  rule  installed  in  an  active  rule  table  (a  hash 
table),  keyed  by  the  object  identifier  for  the  trigger  rela¬ 
tion.  A  list  is  maintained  in  the  active  rule  table  for  all 
rules  associated  with  a  given  trigger. 

When  an  assertion  or  denial  is  made  to  a  relation, 
any  rules  indexed  by  that  relation  are  selected  from  the 
active  rule  table  and  tested. 

A  rule  is  always  tested  at  least  once:  when  it  is 
activated.  This  ensures  that  any  pending  conditions  will  be 
serviced  before  the  rule  enters  its  triggering  cycle. 

2.  A  Rule  Queue 

Triggered  rules  are  managed  through  a  circular 
queue.  When  a  rule  is  triggered,  a  pointer  to  the  rule  is 
placed  in  the  rule  queue. 

During  the  sweep  phase,  all  rules  in  this  queue  are 
tested.  If  a  rule  succeeds,  it  remains  in  execution  by 
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staying  in  the  rule  queue.  Instead  of  undergoing  continuous 
evaluation,  a  successful  rule  is  reinserted  at  the  end  of 
the  queue.  This  enforces  a  fairness  policy:  each  rule  in 
the  queue  should  get  a  turn  at  evaluation. 

Given  the  nature  of  rule  testing,  only  one  instance 
of  a  rule  needs  to  be  in  the  queue  at  one  time.  Multiple 
instances  will  result  in  wasted  interpreter  cycles  and 
excessive  queue  sizes. 

To  control  this  problem,  a  flag  bit  is  used.  The 
flag  bit  is  contained  in  the  tag  field  (bit  7)  of  the  first 
cell  in  an  active  rule  list.  When  a  rule  list  is  placed  in 
the  queue,  the  flag  bit  is  set.  Subsequent  attempts  to 
insert  the  rule  list  in  the  queue  will  be  ignored  because  of 
the  flag  bit  value.  When  the  rule  list  leaves  the  queue  (by 
being  selected  for  testing) ,  the  flag  bit  is  reset  and 
subsequent  queue  requests  for  the  rule  will  be  accepted. 

3-  Advantages  and  disadvantages  of  Triggering 

Rule  triggering  has  the  following  advantages: 

•  Precision.  The  likelihood  of  triggered  rules  firing  is 
good.  The  strategy  is  much  more  precise  than  the  global 
sweep  strategy  of  the  LISP  prototype. 

•  Simplicity.  The  triggering  mechanism  described  is 
simple,  both  in  concept  and  in  its  supporting 
i  iplementation. 


•  Triggers  are  statically  determined.  The  trigger  is  the 
left-most  relation  of  a  rule.  This  is  a  simple, 
syntactic  distinction  that  is  directly  inferable  from 
the  visual  form  of  a  rule. 

Despite  its  attractive  aspects,  the  trigger  mecha¬ 
nism  just  described  is  too  simple.  To  illustrate  this 
point,  consider  the  following  rule: 


T 


if  El  (x)  ,  -E2  (x)  ->  B2  (x)  . 

The  intent  of  this  rule  is  to  enforce  the  constraint  that  El 
should  remain  a  subset  of  R2. 

Assume  El  and  H2  initially  contain  the  same  tuples. 
If  a  tuple  is  removed  from  R2,  the  relation  contents  are 
different  and  the  constraint  rule  should  fire.  Given  the 
previous  triggering  strategy,  however,  the  rule  will  not  be 
tested.  The  affected  relation  was  E2,  but  the  rule  is  trig¬ 
gered  on  R1. 

4.  Two-Leve 1  Triggering 

A  possible  alternative  to  this  simple  triggering 
method  is  to  index  a  rule  on  every  relation  in  the  antece¬ 
dent.  This  will  guarantee  a  correct  evaluation,  but 
requires  a  complex  index  structure.  Also,  triggering  on 
secondary  relations  is  inefficient  —  these  relations  may  be 
updated  frequently  and  result  in  excessive  testing  for  the 
rule. 

Another  possible  alternative  is  to  determine  the 
point  of  failure.  In  the  following  rule: 

if  *S1  (x)  ,  *R2  ( y)  ->  .  .  . 

the  El  inquiry  may  succeed  and  the  R2  inquiry  fail.  If  the 
B2  relation  is  flagged  as  the  point  of  failure  for  this 
rule,  a  subsequent  assertion  tc  R2  could  be  the  trigger  for 
a  retest  of  the  rule. 

The  difficulty  with  this  strategy  is  determining  the 
point  of  failure.  Consider  the  following  rule: 

if  *R1  (x)  ,  *R2  {x,  y)  ,  *R3  (x,  z)  ,  x  >  y  ->  .  .  . 

Each  of  the  relations  El,  E2,  and  R3  may  have  a  tuple  that 
meets  the  pattern  specification.  There  is  a  dependency, 
however,  among  these  inquiries  and  the  constraint. 
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failure,  then,  may  be  a  failure  of  the  combination  and  not 
of  any  particular  inquiry. 

A  compromise  strategy  is  used  to  solve  this  problem. 
We  call  this  technique  two-level  triggering. 

Using  two-level  triggering,  two  rule  queues  are 
maintained.  One  is  for  active,  triggered  rules  selected 
under  the  original  triggering  strategy.  This  is  the  primary 
rule  queue.  The  second  queue  contains  rules  pending  altera¬ 
tion  of  one  or  more  conditions  to  enable  firing.  This  is 
the  secondary  rule  queue. 

When  a  rule  is  initially  triggered,  it  is  inserted 
in  the  primary  rule  gueue.  If,  when  tested,  none  of  the 
conditions  of  its  antecedent  successfully  match,  the  rule  is 
discarded. 

If,  on  the  other  hand,  at  least  the  trigger  condi¬ 
tion  successfully  matches  (but  the  combination  fails) ,  the 
rule  is  entered  into  the  secondary  gueue.  The  rules  of  the 
secondary  queue  are  tested  after  the  rules  of  the  primary 
queue  have  been  expended. 

Once  inserted  into  the  secondary  queue,  rules  will 
remain  under  evaluation  for  possible  firing.  A  rule  will 
leave  the  secondary  queue  under  two  conditions: 

•  The  rule  fires  and  is  transferred  back  to  the  primary 
g  ueue. 

•  The  rule  fails  to  match  cn  its  trigger  relation  and 
leaves  the  active  queues  completely. 

Two-level  triggering  may  be  inefficient.  Consider 
the  following  rule: 

if  *Employee_Da ta (name,  salary),  salary  >  10000  -> 
Employee_Data  (name ,  salary/2). 
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If  the  Eaployee_Data  relation  is  normally  not  empty,  two- 
level  triggering  will  perpetually  maintain  this  rule  in 
either  the  primary  or  secondary  rule  queues.  If  many  rules 
hehave  this  way,  the  rule  selection  strategy  degrades  to  a 
global  sweep,  a  worst-case  performance. 

Many  types  of  rules  fair  well  under  two-level  trig¬ 
gering.  The  key  to  efficiency  for  this  strategy  lies  in 
the  use  of  the  trigger  relation.  This  relation  should 
contain  matching  tuples  only  when  the  rule  is  ready  to  fire. 

1.  THE  APPLICATIVE  COHPONENT 

The  original  description  cf  Omega  did  not  contain  a 
detailed  description  of  the  applicative  component.  Instead, 
it  assumed  that  a  completely  separate  applicative  language, 
such  as  MacLennan1  s  A  [ Hef .  25],  would  be  integrated  into 
the  Omega  environment  to  support  applicative  evaluation. 

The  applicative  component  was  a  minor  issue  in  the  LISP 
prototype,  but  the  fcllow-on  design  had  to  resolve  its  role 
and  form.  Some  of  the  alternatives  considered  were: 

•  Develop  a  general  applicative  interpreter  interface. 
The  Omega  interpreter  and  applicative  interpreters  would 
be  separate  processes  communicating  through  this 
interface. 

•  Integrate  the  code  for  an  existing  applicative 
interpreter  into  the  Omega  structure. 

•  Use  simple  modifications  to  Omega  grammar  and  semantics 
to  add  an  applicative  comporent  to  the  language. 

The  first  option  offers  the  potential  for  multiple  eval¬ 
uation  functions.  In  one  environment,  an  applicative 
expression  may  be  evaluated  by  LISP.  Another  environment 
may  use  an  A  interpreter. 


87 


T- 


■v:  w-.  ir-r_  ;  v^v,- ;  - 


This  option  was  discarded  for  efficiency  reasons. 
Applicative  expressions  use  pointers  to  Omega  structures, 
which  iaplies  shared  memory  access.  Separate  processes 
would  have  to  pass  this  information  through  an  i/o  opera¬ 
tion,  such  as  a  mailbox  transfer  or  a  QNIX  socket  [Eef.  26]. 

The  second  option  was  discarded  because  of  complexity, 
and  the  third  selected  for  the  same  reason.  Minor  modifica¬ 
tions  to  Omega  itself  allowed  the  rapid  development  of  a 
simple  but  useful  applicative  mechanism. 

The  only  completely  new  language  feature  needed  was  the 
function  definition,  which  has  been  shown  in  previous  exam¬ 
ples.  A  function  definition  takes  effect  at  the  same  time 
rule  variables  are  bound. 

The  function  definition  performs  the  following  actions: 

•  The  function  name  is  bound  to  a  system-generated  object 
identifier  and  installed  in  the  current  directory. 

•  The  function  is  separated  into  a  pair,  <fp,  b>,  with 
formal  parameters  (fp)  and  a  function  body  (b). 

•  The  formal  parameters  are  installed  as  free  variables  in 
the  local  symbol  table.  The  variables  of  the  body  are 
then  bound.  These  variables  will  contain  the  stack 
frame  offsets  of  their  corresponding  formal  parameters. 

•  An  allocation  operator  is  linked  to  the  <fp,  b>  pair. 
This  operator  is  used  to  create  space  on  the  binding 
stack  for  formal  parameter  binding. 

•  The  function  structure  is  installed  in  the  object  table, 
keyed  on  the  object  identifier. 

The  function  definition  is  different  from  the  other 
features  of  Omega.  The  mechanism  bypasses  the  "Define1' 
procedure  to  allow  recursive  definitions.  Note  that  the 
installation  of  the  function  name  and  object  identifier  into 
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the  current  directory  is  done  first.  When  the  variables  of 
the  function  body  go  through  the  binding  process,  recursive 
references  to  the  function  name  will  be  handled  properly. 

When  a  function  call  is  evaluated,  the  function  struc¬ 
ture  is  retrieved  frcm  the  object  table.  The  allocation 
operator  is  interpreted,  and  a  frame  created  on  the  binding 
stack  for  the  function's  parameters. 

The  actual  parameters  for  the  function  call,  previously 
evaluated,  are  grouped  together  in  a  list.  This  list  is 
traversed,  and  the  pointer  for  each  actual  parameter  is 
assigned  to  a  slot  in  the  current  binding  stack  frame.  At 
the  completion  of  this  process,  all  formal  parameters  are 
bound . 

The  function  body  is  then  passed  to  the  central  evalua¬ 
tion  function.  At  this  point,  the  function  body  is  simply 
another  rule,  and  it  is  processed  by  the  rule  evaluation 
routines.  The  binding  stack  supports  recursion  in  function 
evaluation. 

This  applicative  mechanism  has  the  advantages  of 
simplicity  and  uniformity  with  the  Omega  syntax.  The  func¬ 
tion  definition,  however,  does  not  conform  well  with  the 
other  constructs  of  the  language.  Also,  lambda  expressions 
and  functionals — key  components  of  an  applicative  language — 
are  not  implemented. 

Despite  its  limitations,  a  variety  of  interpreter 
utility  functions  were  defined  using  this  mechanism.  These 
functions  are  listed  in  Appendix  C. 

M.  PROCEDURES 

With  the  evaluation  and  binding  mechanisms  already 
introduced,  the  implementation  cf  a  procedure  call  mechanism 
is  simple.  The  steps  for  procedure  call  evaluation  are: 
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•  Evaluate  the  tuple  participating  in  the  procedure  call. 
This  tuple  is  analogous  to  the  actual  parameters  of  a 
function  call,  and  is  implemented  as  a  linked  list. 

•  Generate  a  new  relation  object  for  the  mailbox.  This 
object  is  linked  at  the  beginning  of  the  tuple  list. 

•  Assert  the  tuple  into  its  target  relation.  The  asser¬ 
tion  mechanism  will  queue  any  rules  triggered  as  a 
result. 

•  Execute  the  sweep  function  to  evaluate  any  triggered 
active  rules.  The  sweep  function  will  continue  to 
execute  if  there  are  rules  to  fire. 

•  Apply  the  match_first  operation  on  the  mailbox  relation 
to  extract  the  response  from  the  call.  It  is  this 
response  that  is  returned  as  the  result  of  the  procedure 
call. 

While  the  procedure  call  gives  a  measure  of  control  to 
rule  processing,  the  mechanism  is  still  unstructured.  The 
philosophy  of  this  i mplementaticn  is  "make  the  assertion  and 
see  what  happens."  One  possible  consequence  of  the  mecha- 
nisQ  is  multiple  assertions  to  the  mailbox. 

Consider  the  following  active  rule; 

if  *S  (a)  ->  a  ("Yes"),  a  ("Nc")  . 

If  triggered  as  a  result  of  a  procedure  call,  what  is  the 
value  returned  by  the  call?  The  use  of  the  match_first 
operation  and  the  LIFO  implementation  of  relations  will 
return  the  last  assertion  as  the  response.  Other  assertions 
are  ignored.  While  this  convention  seems  tractable,  it  is 
implementation -depen  dent. 


N.  BUILT-IN  FUNCTIONS  AND  PROCEDURES 


While  implementing  the  interpreter,  the  necessity  for 
"har d-wired"  functions  and  procedures  became  apparent.  By 
hard-wired,  we  mean  that  these  mechanisms  are  supported  by  C 
functions  coded  in  the  interpreter,  as  opposed  to  an  imple¬ 
mentation  in  Omega  rules  or  functions.  These  mechanisms  are 
built-in  for  purposes  of  efficiency.  An  example  is  the 
Define  procedure  call. 

In  the  LISP  prototype,  directories  were  implemented  as 
relations  and  the  Define  mechanism  was  implemented  with 
Omega  rules.  By  using  different  representations  for  direc¬ 
tories  and  relations,  the  Define  mechanism  has  a  different 
character  that  reguires  a  more  specific  implementat ■  in. 

Names  like  "Define"  are  implemented  as  system  objects. 
Recall  that  a  block  of  object  identifiers  is  reserved  for 
system  use.  When  a  relation  identifier  is  evaluated,  system 
objects  are  processed  by  a  different  set  of  routines:  one 
for  s ys t em- d ef ined  relations  and  one  for  system-defined 
functions. 

The  object  identifiers  for  these  relations  and  functions 
are  examined  in  a  case  statement,  and  the  appropriate  system 
routine  called.  The  routine  for  Define  receives  the  parame¬ 
ters  (pointers)  for  the  target  directory,  the  name,  and  the 
definition.  The  entry  is  then  installed  in  the  hash  table 
for  the  directory. 

The  steps  reguired  to  add  a  system-defined  function  are 
simple: 

•  An  entry  is  made  in  the  object  header  file.  This  file 
contains  the  definitions  of  reserved  object  identifiers. 

•  An  entry  is  made  in  the  case  statement  for  the  system 
relation  or  function  handler. 
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•  A  directory  entry  is  predefined  in  the  system  initiali¬ 
zation  routine.  This  routine  builds  the  system's  root 

directory. 

This  mechanism  allows  the  access  of  system  routines  from 
Omega  rules.  The  procedures  for  NewBel  and  NewObj  are 
implemented  in  this  way.  Similarly  implemented  is  the 
Display  procedure  call,  which  passes  a  structure  pointer  to 
the  system  pretty  printer. 

This  system  interface  replaces  the  ubiquitous  function 
definitions  of  the  LIS?  prototype.  The  process  required  to 
implement  a  feature  as  a  function  call  or  procedure  call  is 
the  same;  the  mechanism  may  be  selected  that  most  appropri¬ 
ately  models  the  desired  activity.  Appendix  B  lists  the 
built-in  functions  and  procedures  for  the  system. 

0.  CANCEL  OPEBATIONS 

The  implementation  of  cancel  operations  relies  on  two 
features  of  the  interpreter:  the  "match_next"  pointer  into 
a  relation,  and  the  binary  backtracking  algorithm. 

In  the  backtracking  algorithm,  a  successful  evaluation 
of  the  "next_condi  tion"  pointer  indicates  that  the  remaining 
conditions  of  the  antecedent  have  all  been  successfully 
evaluated.  at  this  point  in  the  recursion,  a  pointer  to  the 
match  position  in  the  current  relation  is  available  if  back¬ 
tracking  is  required.  If  the  current  operation  is  a  cancel, 
the  " aatch_next"  pointer  references  the  tuple  that  should  be 
deleted.  This  deletion  is  done  directly  by  marking  the  tag 
field  of  the  tuple. 

The  tuple  is  not  removed  directly  from  the  relation 
because  a  pointer  to  the  tuple's  predecessor  in  the  relation 
list  is  not  available.  The  alternative  to  marking  is  to 
search  the  relation  from  the  beginning,  maintaining  a  pred¬ 
ecessor  pointer,  until  the  canceled  tuple  is  found.  The 
relation  could  then  be  properly  relinked. 
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Marking  was  used  to  avoid  excessive  searching  of  rela¬ 
tions.  Uhen  a  relation  is  scanned  on  subsequent  inquiries, 
the  tuples  marked  for  deletion  are  removed.  In  this  way, 
the  overhead  of  linear  search  is  minimized. 

Maciennan  introduced  the  cancel  operator  as  a  notational 
convenience  [Bef.  1U:  p.  18].  This  simple  construct  demon¬ 
strates  several  desirable  qualities  of  a  language  feature; 

•  The  notation  is  compact,  yet  readable.  The  cancel  oper¬ 
ation  removes  the  necessity  to  code  a  redundant  delete 
operation.  This  saves  space  in  the  source  file  and  in 
the  resulting  parse  tree. 

•  A  potential  source  of  error  is  removed.  The  relation 
name  and  tuple  pattern  of  delete  operations  normally 
correspond  exactly  to  their  counterparts  in  a  presence 
test.  It  is  easy  to  misspell  identifier  names  in  the 
delete  clause. 

•  Cancel  operations  allow  optimization.  The  use  of  the 
"match_next"  pointer  reduces  search  time.  !*'hen  a  delete 
operation  is  evaluated,  there  is  no  easy  way  to  link 
this  to  searches  conducted  when  processing  the  rule's 
antecedent. 

P.  SEQUENTIAL  BLOCKS 

The  implementation  of  the  sequential  block  involves  two 
functional  characteristics:  (1)  the  sequential  evaluation 

of  rules  within  the  block,  and  (2)  the  nested  scoping  of 
free  variables. 

Sequential  evaluation  is  a  natural  consequence  of  the 
interpreter's  design.  The  implementation  evaluates  the 
actions  of  a  rule's  consequent  in  a  lef t-to-righ t  sequential 
order.  The  rules  within  a  sequential  block  are  processed  in 
the  same  way. 
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1 .  A  Single-Pass,  Muiti-Sccpe  Symbol  Table 

The  nested  scopes  of  sequential  blocks  require  an  elabora¬ 
tion  of  the  binding  process  previously  described.  Seeping 
is  handled  by  the  following  steps: 

•  A  block  count  is  maintained  during  binding.  As  a 
sequential  block  is  entered,  this  count  is  incremented. 
When  the  binding  of  the  block  is  complete,  the  block 
count  is  decremented. 

•  Variables  have  a  block  number  and  an  offset.  As  new 

free  variables  are  encountered  in  a  sequential  block, 

their  offset  is  determined.  The  variable  index, 

contained  in  its  head  field,  now  contains  two  elements: 
a  block  number  and  an  offset  within  the  block. 

Free  variables  are  installed  in  a  local  symbol  table 
as  they  are  encountered  in  the  binding  process.  To 

correctly  process  references  to  outer  blocks,  a  multi-scope 
symbol  table  is  required.  This  symbol  table  is  implemented 
as  a  two  stack  structure:  one  stack  maintains  the  variable 

reference  pointers,  the  other  stack  maintains  scope 
pointers.  As  each  variable  is  encountered,  the  symbol  table 
stack  is  searched  from  the  current  stack  top  to  the  base. 
If  found,  the  variable  is  replaced  by  the  definition 
returned.  New  variables  are  installed  in  the  symbol  table 
by  pushing  the  variable  reference  on  the  stack. 

As  a  sequential  block  is  entered,  the  stack  top  for 
the  preceding  scope  is  saved  on  the  scope  stack.  When  the 
binding  of  the  sequential  block  is  complete,  the  predeces¬ 
sor’s  stack  top  is  restored  from  the  scope  stack.  The  scope 
stack  partitions  the  variable  reference  stack  into  the 
appropriate  scopes.  The  structure  is  illustrated  in  Figure 
5.8.  This  symbol  table  structure  is  similar  to  structures 
used  fer  conventional,  block-structured  languages  [Ref.  27: 
pp.  325-327  ]. 
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Figure  5.8  Multi-Scope  Symbol  Table 
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2 •  Evaluation  of  Multi-Scope  Bindings 

The  dynamic  evaluation  of  bindings  requires  modification  to 
process  the  nested  scopes  of  sequential  blocks.  The  evalua¬ 
tion  function  has  the  following  additional  features: 

•  A  global  scope  count.  This  is  incremented  when  a 
sequential  block  begins  execution,  and  decremented  when 
the  sequential  block  is  completed. 

•  Walking  the  links.  The  getbinding  operation  for  the 
binding  stack  must  now  take  scoping  into  account.  To  do 
this,  the  block  number  of  the  variable  is  compared  to 
the  interpreter’s  global  scope  number.  If  these  numbers 
are  not  the  same,  then  the  correct  stack  frame  is 
located  by  traversing  n  links  up  the  binding  stack, 
where  n  =  variable  block  number  -  current  scope  number. 

•  Function  and  procedure  context  switches.  Functions  and 
procedures  require  new  scopes.  This  is  accomplished  by 
the  following  sequence: 

Scope_Save  :=  current_Scope 
current_Scope  :=  0 
Execute  the  procedure  or  function 
current_Scope  :=  Scope_Save 

This  process  is  similar  to  static  link  processing  in  conven¬ 
tional  block-structured  languages,  such  as  described  in 
[Ref.  19:  p.  232-238]. 

This  implementation  does  not  require  separate  static 
and  dynamic  links.  Procedures  and  functions  execute  in 
scopes  separate  from  their  points  of  invocation.  A  single 
set  of  links  in  the  binding  stack  is  sufficient  to  support 
multi-scope  references  and  the  calling  chain  of  functions 
and  procedures. 
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Q.  SIST2H  ISITIALIZJTIOH 


The  system  initialization  sequence  is  similar  to  that  of 
the  LISP  prototype.  The  root  directory  is  initialized  with 
the  names  of  the  systems’s  built-in  functions  and  proce¬ 
dures.  As  in  the  LISP  prototype,  the  directory  has  a  self- 
referencing  entry. 

An  Omega  initialization  file  is  parsed  and  evaluated.  A 
call  to  the  sweep  procedure  propagates  any  rule  activity 
resulting  from  these  rules.  This  initialization  provides 
the  definitions  for  utility  functions  and  procedures.  These 
utility  rules  are  listed  in  Appendix  C. 

To  augment  the  initialization  file,  the  user  may  specify 
an  Omega  file  name  on  the  UNIX  command  line.  The  inter¬ 
preter  will  parse  and  evaluate  these  rules  as  part  of  the 
initialization  process. 

Finally,  the  interpreter  enters  the  read  phase  of  its 
read-evaluate-pr in t- sweep  cycle. 


VI.  STORAGE  MANAGEMENT 


A.  THE  STORAGE  PROBLEM 

The  basic  storage  unit  for  Omega  is  the  cell.  These 
units  are  allocated  dynamically,  to  support  changing  list 
structures,  temporary  results  from  computations,  and 
changing  relation  contents.  Dynamic  memory  allocation  and 
dynamic  typing  make  relation  manipulation  a  flexible  but 
complex  activity. 

The  task  of  freeing  unneeded  storage  ^uickly  became  too 
complex  for  explicit  memory  reclamation  in  the  interpreter 
design.  By  explicit  memory  reclamation,  we  mean  that,  at  a 
certain  section  of  the  code,  it  can  be  determined  that  a 
cell  is  no  longer  needed  and  a  call  to  a  reclamation  routine 
can  be  immediately  made. 

Reclamation  is  complicated  by  memory  sharing.  This 
sharing  is  a  natural  consequence  of  the  design  of  Omega,  and 
comes  from  pattern-matching  and  reuse  of  active  rule 
structures. 

Consider  the  following  rule: 
if  B1(x),  -*R2  (x)  ->  R2  (x)  . 

When  tuples  are  asserted  to  the  relation  R2,  two  possible 
strategies  may  be  used: 

•  Copy  the  structure.  The  complete  tuple  structure  is 
copied,  and  the  copy  added  to  the  R2  relation. 

•  Share  the  structure.  The  match  operation  returns  a 
pointer  to  the  tuple  in  B1.  It  is  this  pointer  that  is 
bound  to  the  variable  z,  and  available  for  inclusion  in 
R2.  If  the  structure  is  net  copied,  the  pointer  added 
to  R2  refers  to  the  same  structure  as  that  in  Rl. 
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Consider  another  rule: 


if  *R1  (1)  ->  E2  ([1,  2,  3])  . 

The  assertion  to  B2  adds  a  tuple  generated  by  a  list  denota¬ 
tion  in  the  rule  —  this  denotation  is  linked  into  the  rule 
structure.  As  in  the  previous  example,  the  assertion  mecha¬ 
nism  may  choose  to  copy  the  structure  or  share  the 
structure. 

Structure  sharing  is  preferable  for  two  reasons:  space 
and  time.  Structure  sharing  obviously  reduces  storage 
requirements  by  allowing  multiple  references  to  the  same 
storage  areas.  Of  more  importance  in  this  implementation  is 
a  reduction  in  execution  time.  The  tuples  of  a  relation  may 
be  arbitrarily  complex  list  structures.  Copying  these 
structures  continually  is  an  execution  overhead  that  struc¬ 
ture  sharing  avoids. 

B.  STORAGE  ALLOCATION  AND  THE  UNIX  VIRTUAL  ADDRESS  SPACE 

The  implementation  uses  the  storage  allocator  provided 
in  the  UNIX  C  library.  The  allocation  routine  is  malloc. 
The  reclamation  routine  is  free.  [Ref.  26] 

To  understand  how  these  routines  work,  a  description  of 
the  UNIX  virtual  memory  map  is  useful.  An  executing  process 
has  its  virtual  memory  divided  into  three  logical  areas:  a 
text  segment,  a  data  segment,  and  a  stack  segment  [Ref.  26]. 

The  text  segment  contains  the  program  code.  This 
segment  is  normally  shared  and  re-entrant.  The  stack 
segment  is  used  for  the  system's  runtime  stack.  The  stack 
begins  at  the  highest  possible  virtual  address,  and  grows 
down.  The  stack  area  is  automatically  extended  as  required. 

The  data  segment  consists  cf  two  sections:  initialized 
and  uninitialized  storage.  The  initialized  storage  area 
contains  statically  allocated  storage  declared  in  the 
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program.  In  this  implementation,  the  binding  stack,  symbol 
table  stack,  and  rule  queues  are  implemented  as  arrays. 
Their  storage  allocation  appears  in  the  initialized  storage 
area. 

The  uninitialized  storage  area  is  used  for  dynamic 
memory  allocation.  Calls  to  malloc  will  extend  this  area. 
Calls  to  free  will  reclaim,  compact,  and  free  virtual 
storage  where  possible. 

The  maximum  sizes  for  the  stack  and  data  segments  are 
system-dependent  and  locally  tailored  to  achieve  desired 
performance  goals.  The  system  used  for  this  work  has  the 
following  limits  set: 

data  segment  --  6112  kbytes 
stack  segment  --  512  kbytes 

This  organization  is  illustrated  in  Figure  6.1 

Malloc  allocates  memory  aligned  on  word  boundaries. 
Structure  storage  requirements  are  rounded  to  the  next  four 
byte  multiple  based  on  the  32  bit  word  size  of  the  VAX.  The 
consequence  of  word  alignment  is  an  additional  space 
requirement  for  cells.  Even  though  the  design  only  speci¬ 
fies  8  bits  for  the  tag  field,  this  requirement  is  rounded 
to  32  bits.  A  cell  has  12  bytes  allocated,  with  3  bytes  of 
storage  {25  percent)  unused. 

C.  IGNORING  STORAGE  MANAGEMENT 

The  interpreter  was  initially  implemented  with  no 
storage  management  strategy.  Cells  were  allocated  when 
necessary,  but  no  attempt  was  made  to  free  excess  storage. 

This  policy  proved  to  be  unsatisf actor y.  A  lengthy  test 
program  exceeds  the  system  data  segment  limits.  On  one 
test,  the  interpreter  ran  for  10  minutes  before  exhausting 
its  available  memory.  At  this  point,  384,159  cells  had  been 
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allocated  using  4.5  Mbytes  of  virtual  memory  for  cell 
storage. 

It  is  possible,  but  not  necessarily  desirable,  to 
increase  the  data  segment  limits  for  a  process.  The  data 
segment  limit  used  during  testing--6  Mbytes — should  be  more 
than  sufficient  for  this  implementation.  A  large, 
constantly  growing  process  also  suffers  from  excessive  swap 
space  requirements  and  a  high  page  fault  rate. 

These  factors  point  out  a  familiar  lesson:  while  virtual 
storage  systems  allow  a  large  address  space,  storage  manage¬ 
ment  is  still  a  major  consideration.  These  policies  are 
particularly  important  in  a  multiuser  operating  system  such 
as  UNIX,  where  excessively  large  processes  can  have  an 
adverse  impact  on  the  user  community. 

D.  OHEGA-SPECIFIC  STORAGE  OPTIMIZATION 

Approaches  were  considered  which  reduce  the  storage 
requirements  of  the  system  by  focusing  on  specific  charac¬ 
teristics  of  the  implementation.  Two  areas  for  optimization 
were:  (1)  eliminate  expression  evaluation  during  pattern¬ 
matching,  and  (2)  reclaim  cell  storage  for  the  initial 
tuples  added  to  relations. 

The  pattern-matching  routines  are  executed  frequently  as 
rules  are  selected  for  test.  An  active  rule  structure  is 
reused,  so  intermediate  results  must  have  separate  storage 
allocated.  Consider  the  following  rule: 

if  *IsManager  (a  ,  x)  ,  Position  ("Manager :  "  ♦  x)  -> 
a  ("is  Manager") 
else  if  *IsManager  (a,  x)  -> 

a  ("is  not  Manager"). 

In  the  Position  inquiry,  the  "+"  represents  string  concat¬ 
enation.  To  evaluate  this  rule,  a  new  tuple  must  be 


generated  to  record  the  results  of  the  concatenation  opera¬ 
tion.  This  tuple  is  then  used  in  the  inquiry.  Cells  such 
as  these  may  be  generated  frequently  during  rule  testing. 

A  possible  optimization  to  this  requirement  is  to 
restrict  expressions  in  the  antecedent  of  a  rule  to 
constraints.  Strict  pattern-matching  is  supported  primarily 
by  the  binding  stack  and  little  additional  memory  is 
required.  If  expressions  are  limited  to  constraints,  and 
constraints  shifted  to  the  end  of  a  list  of  antecedent 
conditions,  rule  failures  will  occur  before  the  constraint 
is  evaluated,  minimizing  dynamic  memory  allocation.  Tests 
conducted  using  this  strategy  showed  a  decrease  of  cell 
allocation  ranging  from  10  percent  to  40  percent. 

While  this  strategy  reduces  memory  requirements,  the 
basic  issue  of  storage  reclamation  is  not  solved.  The 
restriction  on  tuple  expressions  is  significant — the 
programmer  must  now  remember  this  as  an  exception  to  syntax 
and  semantics. 

One  possible  alternative  tc  the  above  strategy  is  the 
use  of  a  separate  storage  allocator  and  reclamation  routine 
for  intermediate,  temporary  storage.  This  approach  was  not 
pursued  because  a  more  general  solution  to  the  storage 
management  problem  was  needed. 

Certain  types  of  relations  tend  to  be  small,  with  a 
cardinality  of  1  or  0.  Consider  the  following  rule: 

if  *Push(a,  x,  1)  -> 
a(£x:l]). 

This  rule  executes  a  Push  operation  by  cons’ing  the  member  x 
onto  the  list  1. 

While  multiple  agents  may  have  requests  to  Push  active 
at  the  same  time,  a  typical  situation  is  where  Push  contains 
a  single  request  which  is  serviced  and  promptly  removed.  A 
simple  strategy  optimizes  storage  for  such  relations. 
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k  relation  list  has  a  collection  of  cells  which  we  refer 
to  as  tuple  headers  (illustrated  in  Figure  5.4).  These 
headers  link  pointers  into  the  relation  list  which  refer  to 
the  actual  structures  of  the  tuple  members.  While  the 
pointers  may  change,  the  number  of  header  cells  is  dependent 
on  the  tuple  cardinality.  This  cardinality  tends  to  remain 
fixed  after  it  is  dynamically  determined. 

When  the  first  tuple  is  added  to  a  relation,  the  header 
cell  requirements  are  allocated.  A  cancel  will  flag  this 
tuple  as  deleted  by  marking  the  tag,  but  the  tuple  will 
remain  linked  into  the  relation  list.  A  subsequent  asser¬ 
tion  may  then  reuse  these  header  cells  for  the  next  tuple. 

This  strategy  allows  a  simple  optimization  of  relation 
storage  requirements.  Early  tests  of  this  strategy  indicate 
a  potential  10  percent  reduction  in  cell  allocation.  The 
strategy  postpones  memory  exhaustion  but  doesn't  prevent  it; 
a  more  general  storage  management  policy  is  still  required. 

E.  REFEREHCE  COUNTIHG 

Reference  counting  was  selected  for  cell  reclamation. 
This  technique  is  described  extensively  in  the  literature. 
Our  algorithms  are  based  on  the  material  presented  in 
[Bef.  19;  pp.  440-442]  and  [Bef.  28:  pp.  383-384  ]. 

The  implementation  of  reference  counting  required  the  addi¬ 
tion  of  a  reference  count  field  in  the  cell  structure  and 
some  simple  management  routines. 

Since  25  percent  of  cell  storage  is  wasted,  the  inclu¬ 
sion  of  a  reference  count  field  bears  no  additional  cost. 
The  reference  count  field  is  implemented  as  a  16  bit  signed 
integer,  although  a  smaller  field  would  be  sufficient. 
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The  reference  counting  routines  are  as  follows: 


•  IncrEef  —  Increment  a  cell  reference  count: 

IncrRef [ p  ]  : 

if  p  =  Nil 

ret  urn; 

else 

pSrefcount  :=  j3refcount  +  1 

endif 

end. 


•  DecrBef  —  Decrement  a  ceil  reference  count: 

DecrBef [ p  ]  : 

if  p  =  Nil 

return ; 

pSrefcount  :=  pSrefcount  -  1 
if  pSrefcount  <=  0 

if  pa  is  a  string  cell 

free  string  storage 
else  if  pa  is  a  list  ceil 
DecrRef[  pahead  ] 

DecrRef[  pStail  ] 

endif 
free  p 

endif 

end  DecrRef 


When  a  cell  for  an  atom  is  created,  its  reference  count 
is  initialized  to  zero.  Reference  counts  are  altered  when 
pointer  references  change.  This  occurs  in  the  following 
routines: 


•  NevCell  —  Create  a  new  list  cell.  The  algorithm  is: 

h'ewCell[x,  y]: 

p  :=  malloc[ celisi ze] 
pc&refcount  :=  0 
pShead  : =  x 
p5)tail  y 
IncrRef[ x ] 

IncrRef[  y] 
return  p 
end  NevCell 


•  SetKead  —  Change  the  head  pointer  for  a  cell.  This  is 
the  rplaca  function  of  LISP: 

SetHead[x,  y]: 

IncrRef[  y]; 

DecrRef [ xShead ] ; 
x3head  :=  y 
end  SetHead 


•  SetTail  —  Change  the  tail  pointer  for  a  cell.  This  the 
rplacd  function  of  LISP: 

SetTail^x,  y]: 

IncrRef[ y ] 

Deer Ref [  xaitail] 
xStail  :=  y 
end  SetTail 


Reference  counts  also  need  to  reflect  the  references  of 
a  recursive  implementation.  To  illustrate  this  point, 

consider  the  following  interpreter  routine  to  implement 
multiplication: 
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Mult[x,  y]  : 

Ir.crRe  f[  x  ] 

IncrRef£  y  ] 

temp  :=  Maklnt[  xiDhead  *  ya)head] 
DecrRef£ x  ] 

DecrRef£  y  ] 
return  temp 
end  Mult. 


Before  its  invocation/  the  arguments  to  Mult  have  been 
recursively  evaluated.  If  these  parameters  involved  expres¬ 
sions,  then  either  parameter  may  be  an  intermediate  result. 
The  IncrRef  operations  reflect  the  Mult  routine's  references 
via  its  formal  parameters.  After  completion  of  the  multipli¬ 
cation,  the  references  are  decremented  with  DecrRef,  which 
will  free  intermediate  results  that  are  no  longer  required. 

Reference  counts  must  remain  consistent,  so  an  analysis 
of  local  references  throughout  the  interpreter  was  required. 
A  point  of  interest  is  the  binding  stack:  the  bind  operation 
must  increment  a  cell's  reference  count  while  the  unbind 
operation  must  decrement  the  reference  count.  The  determi¬ 
nation  of  these  specific  reference  counting  points  proved  to 
be  a  tedious  process,  although  still  more  tractable  than 
explicit  reclaration. 

Reference  counting  offers  the  following  advantages: 

•  Simplicity.  The  data  structures  and  algorithms  are 
supported  by  the  existing  recursive  interpreter  design. 

•  Immediate  reclamation.  Jnneeded  storage  is  reclaimed 
i mmediately. 

•  Uniform  computational  requirements.  The  overhead  of 
storage  reclamation  is  spread  out  over  the  execution 
time  of  the  interpreter. 
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TABLE 

XII 

Omega  Eelation  Characteristics:  The 

Sieve 

Sample  Frequency:  149 

Characteristic  Mean 

Std  Dev 

Mode 

Eelation  1.0 

cardinality 

0.0 

1.0 

Tuple  2.6 

cardinality 

0.5 

3.0 

Object  Table  Collisions: 
Collision  List  Length 

Frequency 

1 

2694 

TABLE  XIII 

Execution 

Times:  Quicksort 

System 

Execution  Time  (secs) 

Omega 

142 

Prolog 

LISP 

27 

Inter pr  eted 
Compiled 

81 

40 

Comparative  benchmarks  were  not  written  for  this 
problem,  and  timing  comparisons  are  not  shown.  The  execu¬ 
tion  profile  for  the  simulation  is  given  in  Table  XVII,  data 
type  frequencies  are  shown  in  Table  XVIII,  and  relation 
statistics  are  shown  in  Table  XIX. 


TABLE  X 

Execution  Profile  Summary 

The  Sieve 

%  Execution 
Time 

No. 

Calls 

Nam  £ 

Descr 

13.7 

11  8635 

eval 

evaluation  function 

4.2 

16462 

tupl 

eval  tuple/args 

4.0 

29425 

mal loc 

memory  allocation 

2.9 

28169 

new  cell 

create  new  cell  j 

2.7 

12348 

fnapl 

apply  fn  to  args 

TABLE  XI 

Data 

Type  Frequencies: 

The  Sieve 

Type 

Frequency 

%  of  Total 

Lists 

Op  List 

1990 

7 

Data  List 

20  372 

72 

Atoms 

Integer 

3266 

12 

String 

1146 

4 

Boolean 

423 

2 

Object 

23  2 

1 

Variable 

76  1 

3 

5.  A  Simula  tion  Program 

This  example  is  a  Monte  Carlo  simulation  of  a  three 
node  message  switching  network.  It  is  a  more  complex 
program  than  the  preceding  benchmarks,  and  the  interpreter 
exhibits  a  wider  range  of  activities.  The  source  code  for 
the  simulation  rules  is  listed  in  Appendix  E. 
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TABLE  VIII 

Omega  Relation  Characteristics:  Factorial 


Sample  Frequency: 

2078 

Characteristic 

Mean 

Std  Dev 

Mode 

Relation 

cardinality 

1.0 

0.0 

1.0 

Tuple 

cardinality 

2.0 

0.  1 

2.0 

Object  Table  Collisions: 
Collision  List  Length 

Frequency 

1 

43126 

TABLE  IX 

Execution  Times:  The  Sieve 


System 


Execution  Time 


Omega  19 
Prolog  1 1 
LISP 

Interpreted  9 
Compiled  3 


(secs) 


The  timing  results  are  shown  in  Table  XIII.  These 
times  are  based  on  executing  an  ascending  sort  on  a  list  of 
150  integers  initially  arranged  in  descending  order  (an 
0(n2)  undertaking  for  Quicksort).  An  execution  profile 
summary  is  given  in  Table  XIV,  and  Table  XV  contains  the 
data  type  frequencies.  The  relation  characteristics  of  the 
benchmark  are  shown  in  Table  XVI. 


TABLE  TI 

Execution  Profile  Summary:  Factorial 
%  Execution  No. 


Time 

Calls 

Nam  e 

Descr 

14.8 

155457 

eval 

evaluation  function 

3.7 

32059 

malloc 

memory  allocation 

3.2 

24001 

bin  op 

binary  operation 

2.  1 

3  034  6 

newcell 

create  a  new  cell 

1.9 

9097 

tupl 

eval  tuple/args 

TABLE  VII 

Data 

Type  Frequencies: 

Factorial 

Type 

Frequency 

%  of  Total 

Lists 

Op  List 

2001 

7 

Data  List 

9777 

32 

Atoms 

Integer 

1553  0 

51 

String 

160  7 

5 

Boolean 

50  2 

2 

Cb iect 

226 

1 

Variable 

720 

2 

4 .  Quicksort 

This  benchmark  exercises  the  Omega  procedure  call 
and  pattern-matching  mechanisms.  The  Quicksort  splits 
lists,  recursively  sorts  the  sublists,  and  combines  the 
results.  The  Prolog  version  is  taken  from  the  example  given 

in  [Ref.  21:  p.  147]. 
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TABLE  IV 

Data  Type  frequencies:  Pattern-matching 


Type 

Lists 
Op  List 
Data  List 
Atoms 
Integer 
String 
Boolean 
Object 
Variable 


Frequency 


2053 

8815 

2028 
1  141 
3004 
235 
747 


%  of  Total 


1 1 
49 

11 

6 

17 

1 

4 


TABLE  V 

Execution  Times:  Factorial 


System 

Execution  Time  (secs) 

Omega 

23 

Prolog 

LISP 

99 

Interpreted 

12 

Compile  d 

4 

performed  by  the  applicative  component.  The  Prolog  version 
is  based  on  an  example  given  in  [Ref.  21:  p.  157]. 

The  timing  results  for  this  benchmark  are  shown  in 
Table  IX.  These  times  are  based  on  a  sieve  list  of  350  inte¬ 
gers.  A  summary  of  the  Omega  execution  profile  is  given  in 
Table  X,  data  type  distributions  are  given  in  Table  XI,  and 
relation  characteristics  in  Table  XII. 


TABLE  II 

Execution  Times:  Pattern-matching 


System 


Execution  Time 


Omega  212 
Prolog  10  2 
LISP 

Interpreted  N/A 
Compiled  230 


(secs) 


TABLE  III 

1  Execution  Profile 

1 

Summary:  Pattern-matching 

%  Execution 

No. 

Time 

Calls 

Nam  e 

Descr 

30.5 

2021016 

unify 

pattern- matching 

10.0 

1010985 

egu 

list  equality  test 

5.7 

5035 

match  s 

linear  list  search 

4.  4 

1 00400 

FreeBlnd 

reset  frame  bindings 

0.9 

70019 

eval 

evaluation  function 

Omega  type  distribution  for  this  benchmark,  and  Table  VIII 
shows  the  relation  characteristics. 

3 •  A  Prime  Number  Sieve 

The  third  benchmark  is  a  prime  number  generation 
program.  The  benchmarks  use  a  sieve  algorithm  to  remove 
prime  number  multiples  from  a  list  of  numbers.  This  is  an 
interesting  benchmark  for  Omega  in  that  the  sieve  is  driven 
by  rules,  but  the  major  computation--removing  m ultiples--is 


execution  percentage  for  a  routine  is  shown  to  be  5  percent, 
its  relative  impact  is  approximately  10  percent  in  unpro¬ 
filed  execution. 

1 .  A  Pattern-Matching  Test 

This  benchmark  asserts  a  common  tuple  in  two  rela¬ 
tions,  followed  by  1000  disjoint  assertions  to  each.  A 
pattern-match  search  finds  the  common  tuple.  The  search 
requires  more  than  2  x  106  pattern-match  tests,  a  worst-case 
performance. 

The  Prolog  version  is  similar,  with  assertions  made 
to  the  Prolog  rule  base.  Prolog  searches  the  rule  base  from 
top  to  bottom.  The  common  clauses  are  asserted  and  subseq¬ 
uent  clauses  placed  before  these  using  the  asserta  predicate 
[Ref.  21;  p.  105]. 

We  include  a  LISP  implementation  of  a  nested  loops 
search,  although  this  is  a  simplification  of  the  pattern¬ 
matching  process  of  Omega  and  Prolog.  Only  a  compiled  LISP 
version  was  tested  because  an  interpreted  version  is  at  an 
unfair  disadvantage  when  competing  with  the  direct  implemen¬ 
tations  of  this  process. 

The  timing  results  for  this  benchmark  are  shown  in 
Table  II.  A  summary  of  the  Omega  execution  profile  is  shown 
in  Table  III,  and  type  information  is  shown  in  Table  IV. 
Relation  characteristics  are  not  shown  for  this  test. 

2 *  Factorial  Functions 

This  benchmark  exercises  the  applicative  component 
of  the  interpreter.  A  recursive  factorial  function  is 
executed  500  times,  with  each  call  computing  Fact[15]. 
Larger  factorials  are  not  used  because  both  Franz  LISF  and 
Omega  experience  integer  overflew  in  their  computation. 

Timing  results  are  shown  in  Table  V,  and  an  Omega 
execution  profile  summary  in  Table  VI.  Table  VII  shows  the 


3 .  Omega  Statistics 


Besides  benchmark  and  profiling  measurements,  addi¬ 
tional  information  was  collected  to  begin  a  characterization 
of  Omega  program  behavior.  This  information  included: 

•  Data  type  frequencies. 

•  Hash  collisions  in  the  object  table. 

•  Relation  characteristics:  relation  cardinality  and  tuple 
cardinality. 

The  last  two  areas  are  dynamic  characteristics  which  change 
as  rules  fire  and  alter  the  database.  These  measurements 

were  taken  using  a  sampling  technique:  object  table  meas¬ 
urements  were  made  immediately  after  each  rule  evaluation. 

B.  TEST  RESULTS 

Benchmark  programs  were  tested  using  two  different 
versions  of  the  interpreter.  The  versions  were: 

•  The  standard  interpreter  without  reference  counting. 

•  A  version  compiled  with  the  gprof  profile  option  and 
containing  object  table  and  cell  measurement  routines. 

The  overhead  of  measurement  and  profiling  necessitated  the 
separate  compilations. 

The  execution  profiles  produced  by  gprof  are  extensive. 
These  are  summarized  and  included  in  profile  summary  tables, 
with  the  profiling  information  for  the  five  most  expensive 
(in  execution  time)  routines  shown.  The  percentages  given 
in  these  profile  summaries  are  taken  directly  from  the 
profile  reports,  and  reflect  the  large  overhead  of  the 
profiler.  The  profiling  routines  typically  consumed  about 
50  percent  of  the  total  execution  time.  Thus,  if  an 
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2 .  Benchmarking 

In  this  chapter  we  present  a  collection  of  simple 
benchmark  programs.  The  performance  of  the  Omega  inter¬ 
preter  is  compared  to  interpreted  Franz  LISP,  compiled  Franz 
LISP,  and  the  C-?rolog  interpreter.  The  C-Prolog  inter¬ 
preter  is  a  VAX  Prolog  implementation  descended  from  the 
DECs ystem-1 0/20  Prolog  system  [Bef.  31  and  32].  These 
systems  are  all  written  in  C. 

These  benchmarks  are  net  intended  as  an  evaluation 
of  C-Prolog  or  Franz  LISP,  and  no  effort  has  been  made  to 
write  efficient  Prolog  or  LISP.  Because  these  systems  are 
well-engineered  and  efficient  in  what  they  do,  we  present 
these  benchmarks  as  an  indication  of  the  current  progress  of 
our  implementation.  The  source  code  for  the  benchmarks  is 
included  in  Appendix  D. 

Timing  information  was  obtained  through  calls  to  the 
date  function  of  the  UNIX  command  shell  [Bef.  26].  The 
following  Omega  rule  demonstrates  this  technique: 

if  *gTest  (a)  ->  { 

System  ("date”}  ; 

Qsort  (IotaE[1 ,  150]}; 

System  ("date”}  ; 

}  • 

The  date  function  returns  the  current  system  time  to  the 
nearest  second.  The  test  systems  all  possessed  a  function 
similar  to  the  System  procedure  shown  above,  and  the  over¬ 
head  of  executing  such  a  system  call  should  be  consistent 
between  interpreters.  The  timing  granularity  of  one  second 
required  establishing  benchmarks  of  sufficient  duration  to 
provide  meaningful  comparisons. 
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macro  implementation  results  in  a  savings  of  4 
instructions — a  substantial  improvement  given  the  high 


Function  Implementation 
C  statements  VAX  instructions 


x  =  tag (p) ; 


Push!  -8  (fp) 
calls  tag 
movl  r0,-4  (fp) 


ta< 


return  (p->tag)  ; 


cv  tbl  *4  (ap)  ,  rO 
ret 


Macro  Implementation 

C  statements  VAX  instructions 

#  define  tag  (x)  (x->tag) 


x  =  tag (p) ; 


cvtbl  *-8  (fp)  ,-4  (fp) 


Figure  7.1  Code  generation  for  TAG  function. 


frequency  of  tag  extraction  during  interpretation. 

Replacing  procedural  implementations  with  macros  is 
not  a  panacea.  Macro  implementation  has  at  least  two 
disadvantages: 


Debugging  is  more  difficult.  Macros  are  textually 
expanded  by  a  preprocessor  before  compilation.  The 
errors  that  occur  are  unusual,  do  not  correspond  veil 
with  source  code,  and  may  produce  unexpected  effects. 


•  Profiling  information  is  lest.  An  execution  profile 
pointed  out  the  expense  of  the  tag  function.  Once  coded 
as  a  macro,  the  cost  of  this  code  sequence  is  absorbed 
in  the  routines  where  the  macro  is  expanded. 


VII.  PERFORMANCE  EVALUATION 


A.  METHODOLOGY 

A  progressive  series  of  programs  were  developed  to  test 
features  as  they  were  implemented.  These  programs  assisted 
in  determining  the  interpreter's  reliability  and  execution 
characteristics.  Execution  profiles  and  comparative  bench¬ 
marks  were  used  to  evaluate  behavior  and  performance. 

In  this  implementation,  performance  was  subordinate  to  a 
clear,  workable  design.  Performance  optimization  efforts 
were  started  only  after  the  design  and  implementation  of  a 
series  of  features  were  complete,  with  all  test  programs 
successfully  executing. 

1 .  Execution  Profiling 

The  gprof  call  graph  execution  profiler  [Ref.  26] 
was  an  important  tool  for  evaluating  weak  points  in  the 
performance  of  the  interpreter.  Execution  profiles  pointed 
out  some  immediate  inefficiencies  in  the  implementation  that 
could  be  easily  remedied. 

A  simple  example  is  the  tag  function.  Initially,  a 
function  was  used  to  extract  the  tag  value  from  a  cell.  The 
rationale  behind  this  implementation  was  information  hiding: 
the  details  of  the  cell  structure  were  accessible  to  only  a 
few  handling  routines. 

Execution  profiles  on  pattern-matching  showed  this 
implementation  to  be  costly:  the  interpreter  spent  over  10 
percent  of  its  execution  time  extracting  tags.  To  solve 
this  problem,  the  function  was  rewritten  as  a  C  macro 
[Ref.  22:  p.  86].  The  VAX  instructions  generated  by  the 
alternative  implementations  are  shown  in  Figure  7.1.  The 


field  containing  a  cell  offset  to  the  next  cell  in  the 
structure  instead  of  a  full  pointer.  An  escape  mechanism 
allows  full  pointer  access  where  necessary  [Eef.  30:  p. 
266]. 

The  above  techniques  are  mentioned  as  potential  improve¬ 
ments  in  the  current  allocation  scheme.  These  techniques, 
like  garbage  collection,  require  more  explicit  control  of 
storage  allocation  than  is  offered  by  the  current  design. 

A  potential  storage  savings  can  be  obtained  with  the 
current  tagged  cell  structure  by  embedding  the  tag  in  the 
tail  field.  This  is  a  simple  modification  that  requires 
masking  the  tail  field  value  to  obtain  the  tag  or  tail 
pointer.  If  a  reference  counting  field  is  not  used 
(assuming  garbage  collection  instead)  this  technique 
reduces  the  current  cell  requirement  to  8  bytes,  a  33 
percent  reduction.  Osing  this  encoding  scheme,  the  tail 
pointer  is  restricted  to  a  24  bit  range. 
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Accessing  intermediate  results  is  complicated  by  the 
present  recursive  implementation.  A  possible  solution 
is  to  maintain  a  stack  specifically  for  referencing 
these  strictures  during  a  mark  phase. 

•  Cells  require  a  mark  bit.  The  current  cell  structure 

provides  an  8  bit  tag.  Bits  0  through  5  are  used  for 
the  tag  value,  bit  7  is  used  as  a  flag  on  certain 
structures.  Bit  6  remains  available  for  marking 

purposes. 

•  Complete  storage  access  is  required  for  the  sweep  phase. 
This  immediate  access  implies  that  the  memory  allocator 
must  be  managed  by  the  interpreter.  To  maintain  a 
reasonable  virtual  memory  image,  this  allocator  must 
obtain  and  release  memory  on  page  boundaries,  using 
compaction  whenever  possible. 

G.  SEDUCING  CELL  STOBAGE 

The  current  12  byte  requirement  for  cell  storage  is 
large.  Since  the  cell  structure  is  based  on  the  LISP  model, 
numerous  LISP  techniques  may  be  used  to  reduce  this 
requirement. 

LISP  structures  have  fewer  distinct  cell  types.  Instead 
of  encoding  tag  information  directly,  storage  for  cells  of 
different  types  are  often  allocated  from  noncontiguous, 
separate  sections  of  memory  [Eef.  29].  In  this  way,  the 
address  range  of  a  pointer  provides  the  necessary  type 
informa  tion. 

List  linearization  techniques  are  another  way  to  reduce 
storage  requirements.  These  techniques  attempt  to  maintain 
cells,  normally  linked  via  their  tail  pointers,  in  contig¬ 
uous  storage.  This  allows  a  reduced  tail  field  size,  with  a 


A  major  limitation  of  reference  counting  is  the  diffi¬ 
culty  in  reclaiming  cyclic  structures.  The  design  of  Omega 
prevents  this  problem.  Only  ’’pure"  lists  are  used  and 
rplacz  operations  are  not  defined. 

Seference  counting  places  a  computational  turden-- 
incrementing  reference  counts--at  a  sensitive  point:  memory 
allocation.  The  execution  penalties  associated  with  refer¬ 
ence  counting  are  examined  in  the  next  chapter. 

F.  GARBAGE  COLLECTION 

Garbage  collection  was  not  selected  as  a  storage  manage¬ 
ment  strategy  because  of  the  complexity  of  implementation. 
The  malloc  and  free  routines  offer  a  predefined  storage 
allocation  system,  while  a  garbage  collection  system 
requires  an  explicit  design  of  these  components. 

The  development  of  a  garbage  collector  would  be  an 
interesting  extension  to  the  current  design.  Some  of  the 
considerations  for  a  aark-and-sweep  garbage  collector  are: 

•  Structure  access  is  required  for  the  mark  phase.  This 


phase  needs  to 

structures: 

access  the 

following 

interpreter 

1. 

The  object  table. 

2. 

The  active  rule  table. 

3. 

Rules  under 

evaluation 

by  the  console 

command 

processor. 

4. 

Rules  under 

evaluation 

by  the 

file 

command 

processor. 

5. 

Intermediate 

evaluation . 

results 

generated 

during 

rule 
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TABLE  21? 

Execution  Profile  Summary:  Quicksort 
%  Execution  No. 


Time 

Calls 

Nam  e 

Descr 

13.7 

5.  1 

2.7 

2.  6 

2.0 

717396 

216385 

15  1009 
91975 
143777 

eval 
unify 
malloc 
tupl 
new  cell 

evaluation  function 
pa ttern- matching 
memory  allocation 
eval  tuple/args 
create  new  cell 

TABLE  XV 

Data 

Type  Frequencies: 

Quicksort 

Type 

Freguency 

%  of  Total 

Lists 

Op  list 

1753 

1 

Data  List 

121627 

85 

Atoms 

Integer 

170 

0 

String 

6820 

5 

Boolean 

11777 

8 

Cb  ject 

533 

0 

Va~  .able 

808 

1 

C.  IMPACT  OF  REFERENCE  COUNTING 

The  timing  information  presented  previously  was  taken 
without  reference  counting.  A  separate  version  of  the 
interpreter  was  compiled  with  the  reference  counting 
routines  included,  and  separate  measurements  taken.  The 
impact  of  reference  counting  on  execution  speed  is  shown  in 
Table  XX.  A  summary  of  the  Quicksort  benchmark,  with  refer¬ 
ence  counting  implemented,  is  shown  in  Table  XXI. 
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TABLE  271 

Omega  Gelation  Characteristics:  Quicksort 


Sample  Frequency:  35704 

Characteristic 

Mean 

Std  Dev 

Mode 

Selation 

cardinality 

1.0 

0.0 

1.0 

Tuple 

cardinality 

4.9 

0.7 

5.0 

Object  Table  Collisions: 
Collision  List  Length 

Frequency 

1 

2 

785578 

264 

TABLE  2711 

Execution  Profile  Summary:  Simulation 
%  Execution  No. 


Time 

Calls 

Nam  e 

Descr 

9.4 

211360 

eval 

evaluation  function 

3.3 

63126 

unify 

pattern-matching 

2.9 

63782 

malloc 

memory  allocation 

2.  1 

1221 

vri  te 

system  i/o 

1.8 

35220 

lookup 

hash  table  lookup 

D.  DISCUSS JOB  OF  BES0LT5 

1 .  Performance  Bottlenecks 

The  measurements  presented  in  the  preceding  sections 
provide  some  insight  into  the  effectiveness  of  the  present 
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TABLE  XXIII 

Data  Type  Frequencies:  Simulation 


Type 

Frequency 

5J  of  Total 

Lists 

Op  list 

6125 

11 

Data  List 

26053 

47 

Atoms 

Integer 

2147 

4 

String 

6340 

1  1 

Boolean 

10124 

13 

Object 

2390 

4 

Variable 

2290 

4 

TABLE 

XIX 

Omega  Relation  Characteristics:  Simulation 

Sample  Frequency:  9972 

Characteristic  Mean 

Std  Dev 

Mode 

Relation  5.7 

6.3 

1.0 

cardinality 

Tuple  2.3 

cardinality 

Object  Table  Collisions: 
Collision  List  Length 

0.7 

2.0 

Frequency 

1 

404828 

2 

180974 

3 

26152 

4 

4552 

5 

2761 

6 

1  1 

implementation.  The  execution  speeds  for  the  Omega  bench¬ 
marks  are  consistently  slower  than  C-Prolog  and  Franz  LISP. 
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TABLE  XX 

Reference  Counting  and  Execution  Times 


Benchmark 

w/o  Ref  Counts 

v  Ref  Counts 

%Incr 

Pattern 

212 

223 

5 

match 

Factorial 

23 

30 

30 

Sieve 

19 

25 

32 

Quicksort 

142 

181 

27 

TABLE  XXI 

Profile  of  Quicksort  with  Reference  Counting 
%  Execution  No. 


Time 

Calls 

Nam  e 

Descr 

9.9 

717396 

eval 

evaluation  function 

4.0 

216385 

unify 

pattern-matching 

3.7 

421556 

DecrSef 

decrement  ref  count 

3.3 

541624 

IncrRef 

increment  ref  count 

2.4 

151009 

mal loc 

memory  allocation 

This  performance  is  shown  in  both  applicative  expression  and 
rule  evaluation. 

The  central  evaluation  function,  eval,  consumes  the 
majority  of  execution  time.  This  is  not  surprising  given 
the  present  recursive  implementation:  eval  is  called 

directly  or  indirectly  in  most  operations.  Embedded  in  eval 
are  accesses  of  the  binding  stack  for  atom  evaluation  in 
tuples  and  argument  lists. 

The  high  frequency  of  calls  to  eval  suggest  its 
design  as  a  potential  point  for  optimization.  This 
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optimization  may  include  a  reduction  of  unnecessary  recur¬ 
sive  calls  to  eval.  When  evaluating  interior,  nodes  of  a 
rule  tree,  the  sons  of  a  node  are  always  passed  to  eval, 
which  will  decode  the  tag  and  call  the  appropriate  subordi¬ 
nate  routine.  If  the  required  subordinate  routine  is  known 
at  the  parent  node,  the  intermediate  call  to  eval  may  be 
omitted . 

Another  alternative  is  to  replace  the  recursive  eval 
with  an  iterative  version.  This  requires  the  management  of 
an  explicit  operand  stack,  and  involves  a  major  redesign 
effort.  The  management  of  an  operand  stack  would,  however, 
solve  an  implementation  problem  for  garbage  collection 
discussed  in  the  previous  chapter. 

The  patt ern- matching  routine  becomes  significant  in 
extended  rule  processing,  as  shown  by  the  Quicksort  and 
network  simulation  tests.  Be  note  similarities  between  eval 
and  the  pattern- matching  routine  unify: 

•  Both  routines  are  heavily  exercised. 

•  Both  routines  access  the  binding  stack  when  evaluating 
free  variables. 

•  Both  routines  are  recursive. 

The  recursive  algorithm  for  pattern-matching  is  simple  and 
elegant.  An  iterative  version  would  be  more  complex,  but 
may  provide  a  performance  gain. 

A  final  area  for  performance  improvement  is  storage 
management.  The  storage  allocation  routine,  malloc,  and 
routines  that  call  it,  such  as  newcell,  consistently  rank 
high  in  the  execution  profiles.  Our  implementation  of 
reference  counting  for  storage  reclamation  proved  to  be 
expensive,  with  a  30  percent  ircrease  in  execution  time  for 
extended  tests.  These  results  make  garbage  collection 
appear  to  be  a  desirable  alternative.  Hardware  support  for 
reference  counting  could  also  provide  a  solution. 
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2 •  Relati on  Statistics 

The  statistical  information  gathered  on  relations 
provides  some  evidence  to  support  previous  conjectures: 

•  Small  relations  are  commonplace.  The  mode  for  relation 
cardinality  was  1.0  in  every  test.  These  statistics 
will  vary  depending  on  the  application,  and  generaliza¬ 
tions  can’t  yet  be  made  based  on  the  limited  tests 
conducted. 

•  Object  identifiers  hash  well.  The  object  table  colli¬ 
sion  results  indicate  an  even  distribution  of  hash 
values.  Collisions  in  the  object  table  slow  down  rela¬ 
tion  list  lookup,  an  important  part  of  the  synchronous 
procedure  call.  Only  in  the  simulation  test  did  hash 
table  lookups  begin  to  become  significant  in  the  execu¬ 
tion  profiles.  This  coincides  with  the  increased  number 
of  objects  generated  and  an  increased  collision 
frequency  in  the  object  table. 


VIII.  OBSERVATIONS,  RECOMMENDATIONS,  AND  CONCLUSIONS 

A.  OBSERVATIONS  ON  CHEGA 

1 •  Programming  Experie nee 

Our  experience  with  Omega  programming  is  reflected 
in  the  rules  listed  in  Appendices  C-E.  We  believe  these 
examples  demonstrate  a  variety  of  applications  which  have 
simple  solutions  in  Omega  rules. 

An  important  body  of  rules  are  the  system  utilities 
listed  in  Appendix  C.  Included  are  relation  copying  utili¬ 
ties,  an  extension  to  the  system  pretty  printer,  and  a  help 
facility.  The  last  application  shows  a  simple  use  of  the 
System  procedure  call  to  list  help  files  at  the  user's 
terminal.  This  technique  could  be  extended  to  use  the  Omega 
interpreter  as  a  rule-based  driver  for  the  UNIX  command 
shell. 

The  longest  and  most  significant  application  is  the 
simulation  model  listed  in  Appendix  E  and  profiled  in  the 
previous  chapter.  We  include  this  example  as  an  event- 
driven,  state-transition  problem  which  is  readily  expressed 
as  rules  of  the  form; 

if  Clock  £ 1 1 ) ,  *  Event (t 1 ,  e)  -> 

ProcessEvent  [e}  . 

2 •  Omega  and  Prolog 

The  benchmarking  examples  of  the  previous  chapter 
presented  rules  in  Prolog  and  Omega  that  are  similar  in 
form.  Both  these  languages  use  pattern-directed  invocation 
for  rule  selection,  and  both  languages  are  intended  for 
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general  programming  applications.  Despite  similarities/ 
these  languages  have  fundamental  differences. 

Omega  uses  forward  inference/  Prolog  uses  backward 
inference;  Omega  programmers  and  Prolog  programmers  think 
in  different  directions.  To  design  an  Omega  rule,  one  uses 
the  train  of  thought:  “Given  the  current  state  of  the 

system,  generate  the  next  state.”  A  Prolog  rule  is  designed 
with  the  thought:  "To  prove  this  goal,  it  is  necessary  to 

prove  these  subgoals. "  Prolog  relies  on  a  theorem-proving 
approach.  Omega  on  a  data-driven  approach. 

These  opposite  control  strategies  are  reflected  in 
different  implementation  technigues: 

•  Prolog  recursively  evaluates  its  rules  from  a  goal 
stack.  This  technique  often  allows  intermediate  storage 
allocation  from  stack  structures.  This  method  of  allo¬ 
cation  and  reclamation  is  simpler  than  the  heap  alloca¬ 
tion  used  by  Omega  and  LISP,  and  results  in  a  faster 
cons  operation  [fief.  32:  p.  114].  This  performance  is 
reflected  in  the  Quicksort  benchmark  of  the  previous 
chapter. 

•  Theorem  proving  requires  backtracking.  Prolog  selects 
rules  from  its  rule  base  to  prove  subgoals.  If  multiple 
rules  for  a  subgoal  are  present,  they  will  be  selected 
and  tested  until  the  subgoal  is  proven  or  all  possible 
rules  fail.  Backtracking  between  rules  requires  a  more 
general  pattern- matching  technique  in  Prolog  than  Omega. 
In  Prolog,  variables  may  be  bound  to  variables.  In 
Omega,  a  rule  fires  or  it  doesn’t — there  is  no  require¬ 
ment  for  backtracking  between  rules,  and  variables  are 
bound  only  to  objects  and  values  in  the  database. 

Programming  problems  may  be  solved  by  either  forward 
or  backward  inference.  To  illustrate  this  point,  we  use  the 
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missionaries  and  cannibals  problem  [Eef.  33:  p.  51],  a 
simple  state-space  search  example.  The  Omega  and  Prolog 
rules  for  this  problem  are  listed  in  Appendix  D. 

In  the  missionaries  and  cannibals  problem,  a  simpli¬ 
fied  description  of  the  Omega  rules  is: 

if  *State(x,  path),  GoaiState[x]  -> 

Displayn {path} 

else  if  *State  (x,path)  ,  Is  legalState[  x  ], 

-»member[  x ,  path]  -> 

GenerateNewStates  {x,  [  x:  pa  th  ]} 
else  if  *State (x,path)  -> . 

Given  a  starting  state,  the  Onega  rules  will  generate  all 
possible  new  states  that  may  be  reached  from  that  state. 
This  process  continues  until  all  combinations  of  legal 
states  have  been  tested.  No  backtracking  is  required  in 
these  rules — successful  states  continue  to  fire,  and  unsuc¬ 
cessful  states  are  removed  from  the  computation.  We  main¬ 
tain  a  list  of  previous  states  in  the  variable  path  to 
prevent  cycles. 

A  simplified  version  of  the  Prolog  rules  for  this 
problem  is: 

goals tate (X , Path)  :- 
finalstate  (X)  , 
print (Path)  . 
goals  tate  (X  , Path)  :- 

not  member  (X,Path)  , 
legalState  (X)  , 
possibleNextState  (X, I) , 
goalstate  (Y,[  XI  Path])  . 

In  the  Prolog  version,  the  predicate  possibleNextState  will 
bind  the  variable  Y  to  a  new  state  that  can  be  reached  from 
X.  In  its  attempt  tc  "prove”  the  starting  goal  state,  all 


possible  state  combinations  will  be  generated  by  back¬ 
tracking  on  possibleNextState.  We  observe  Prolog  exploring 
new  states  through  backtracking  where  Omega  relies  cn  the 
generation  of  new  states  in  the  database. 

Certain  classes  of  problems  lend  themselves  well  to 
the  natural  recursion  inherent  in  Prolog.  The  Quicksort 
rules  of  Appendix  D  are  a  model  of  brevity  and  clarity.  We 
suggest  that  event-driven  or  data-driven  applications,  such 
as  the  simulation  example  of  Appendix  E,  are  better 
described  through  Omega.  Omega  was  developed  as  a  high- 
level  language  for  programming  environment  description  and 
implementation.  This  family  of  applications  are  represented 
more  naturally  through  forward  inference  descriptions. 

3 .  The  Product! on  Rule  as  a  Programming  Paradigm 

Both  Omega  and  Prolog  use  the  production  rule  as  the 
programming  paradigm.  How  easy  is  it  to  program  with 
production  rules?  We  consider  this  to  be  an  application- 
dependent  quality.  A  problem  can  be  effectively  described 
with  production  rules  if  the  following  characteristics 
apply: 

•  The  problem  can  be  decomposed  into  a  set  of  small, 
cause/effect  subproblems.  Each  subproblem  is  described 
by  a  single  rule  or  small  set  of  rules. 

•  The  subproblems  are  independent,  and  reguire  minimal 
communication  between  rules. 

The  independence  of  rules  allows  the  programmer  to 
add  or  remove  rules  without  concern  for  the  impact  of  these 
changes  on  other  rules  in  the  active  rule  list.  In  our 
current  design,  the  rule  denotation  is  the  unit  of  rule 
organization.  Thus,  a  goal  for  a  manageable  rule  structure 
is  independence  of  rule  denotation  sets. 


A  significant  limitation  of  most  production  rule 
systems  is  a  lack  of  meaningful  semantic  composition,  the 
inability  to  compose  a  complex  action  from  a  collection  of 
previously  defined  simpler  actions.  Rosenchein  writes: 


[In  production  systems]  tests  and  transformations  are 
sophisticated  and  are  designed  to  implement  constructs 
found  in  various  applications.  However,  there  is  gener¬ 
ally  no  way  to  symbolize  composition  of  operations  in  a 
transparent  way.  Complicated  tests  and  actions  have  to 
be  simulated  by  groups  of  rules  whose  coordination  is 
not  symbolized  in  the  program  or  graced  with  a  mnemonic 
name.  The  more  complicated  the  tests  and  actions,  the 
more  severe  the  coordination  problems.  This  is  typical 
of  programs  written  at  one  level  of  abstraction,  no 
matter  how  sophisticated  the  primitive  operations. 
[Ref.  34:  p.  535] 


Omega  provides  some  potential  solutions  to  this 
problem.  The  object-oriented  approach  of  the  language 
allows  the  partitioning  of  related  data  and  rules  through 
directories  and  classes.  This  organization  of  the  name 
space  provides  the  first  step  in  a  hierarchical  composition 
of  rule  activity. 

The  second  step  is  the  procedure  call  mechanism. 
This  mechanism  serves  as  an  invocation  trigger  for  a  collec¬ 
tion  of  rules,  with  a  method  of  integrating  the  outcome  from 
their  actions  into  more  complex  expressions.  The  utility  of 
this  mechanism  is  indicated  by  its  widespread  use  in  the 
examples  presented  in  this  thesis. 

Although  our  programming  examples  are  dependent  on 
the  procedure  call,  we  note  potential  problems  with  the 
mechanism: 


•  The  actions  associated  with  a  procedure  call  may  not  be 
obvious.  The  procedure  call  asserts  a  tuple  to  a  given 

relation,  and  extracts  the  response  from  its  mailbox. 
Multiple  rule  denotations  may  use  the  procedure’s  rela¬ 
tion,  and  fire  as  a  result  of  the  procedure  assertion; 
the  possibilities  for  subtle  side 


effects 


are 


significant.  The  final  effect  of  a  procedure  call  can 
only  be  determined  from  an  analysis  of  all  rules  associ¬ 
ated  with  the  procedure’s  relation  name  (as  defined  in 
its  directory) . 

•  The  procedure  mechanism  does  not  enforce  parameter 
checks.  The  tuple  asserted  in  a  procedure  call  is  anal¬ 
ogous  to  the  actual  parameters  of  a  conventional  proce¬ 
dure  call.  In  Omega,  there  is  no  parameter  counting  or 
type  checking.  Consider  the  following  rule: 

if  *R(a,  x)  ->  displayn(x}. 

If  the  user  mistakenly  enters  "R(100),"  the  assertion 
will  be  made  but  the  rule  will  not  fire  because  of  a 
pattern-matching  failure.  The  procedure  call  "R{100, 
200}"  will  fail  for  the  same  reason.  In  both  of  these 
situations,  no  error  indication  will  be  given. 

There  are  programming  techniques  that  correct  the 
last  problem.  If  we  code  the  rule  as: 

if  *R(a;l)  ->  .  .  . 

the  head/tail  list  specification  will  match  against  any 
tuple.  The  rule  designer  may  then  code  explicit  type  and 
parameter  count  checks  with  an  appropriate  response  to 
errors.  We  use  this  technique  in  the  utility  rules 
contained  in  Appendix  C. 

A  declarative  mechanism  may  also  be  used  to  specify 
the  expected  tuple  size  for  a  given  relation.  Any  devia¬ 
tions  would  trigger  an  error  response. 
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B.  RECOMHENDED  ABEAS  FOB  ADDITIONAL  STUDY 

1 .  Extensions  to  the  Language 

Our  programming  and  implementation  experience  with 
Omega  have  suggested  three  additional  extensions  to  the 
language:  (1)  a  syntactic  distinction  for  free  variables, 
(2)  a  universal  quantifier,  and  (3)  named  rules. 

In  our  current  implementation,  the  distinction 
between  free  and  bound  variables  is  made  when  rules  are 
activated:  if  defined  in  the  class/directory  structure,  the 
variable  is  bound;  if  not  defined,  it  is  considered  free. 

This  strategy  is  a  potential  source  of  error. 
Suppose  we  wish  to  define  a  constant,  and  use  the  following 
definition: 

Define  [Root,  "a",  100}. 

The  selection  of  the  variable  name  a  will  conflict  with  the 
majority  of  our  rule  denotations,  where  this  variable  is 
consistently  used  to  represent  a  mailbox  relation.  The 
activation  and  test  of  the  following  rule: 

if  *T  (a,  x}  ->  a  (2  *  x)  . 

will  result  in  a  type  clash  error.  These  errors  are  subtle, 
and  require  the  programmer  tc  remember  which  names  are 
previously  defined  in  a  given  environment.  To  solve  this 
problem,  free  variables  should  be  syntactically  distin¬ 
guished.  Thus,  the  preceding  rule  may  be  written: 

if  *T  (Sa,  6x)  ->Sa{2  *  Sx). 

Previous  definitions  cannot  adversely  affect  this  rule. 
C-Prolog  uses  a  similar  convention:  free  variable  names 
begin  with  upper  case  letters,  bound  variable  names  begin 
with  lower  case  letters. 
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In  Chapter  2,  we  emphasized  the  point  that  a  rela¬ 
tion  inquiry  is  existentially  quantified.  Consider  the 
following  rule: 

if  CopySel(r1,  r2)  ,  rl(x),  -*r2  (x)  -> 
r2  (x) 

else  if  *CopyRel{r1,  r2)  ->. 

This  rule  implements  a  relation  copying  utility.  The 
programmer's  intent  for  this  rule  is  that  all  tuples  in  rl 
should  be  asserted  to  relation  r2.  Existential  quantifica¬ 
tion  will  select  a  single  tuple  on  each  firing  cycle  for  the 
rule.  Note  that  the  absence  test  on  relation  r2  is  required 
to  ensure  termination. 

A  possible  alternative  is  to  provide  universal  quan¬ 
tification  for  tuple  selection.  With  this  mechanism,  the 
copy  rule  could  be  written: 

if  *CopyRel(r1,  r2)  ,  $r1(x)  ->  r2  (x)  . 

The  symbol  is  used  to  represent  universal  quantifica¬ 

tion.  The  action  of  the  quantifier  is  "for  all  tuples  x  in 
relation  rt,  assert  x  to  relation  r2. "  A  universal  quanti¬ 
fier  offers  the  following  advantages: 

•  The  programmer's  intentions  are  more  clearly  expressed. 
There  is  a  similarity  between  universal  quantification 
and  the  mapcar  function  of  LISP. 

•  Performance  may  be  enhanced.  A  uni  versa.  quantifier 
allows  optimization  by  completing  the  actions  of  the 
rule  in  one  rule  cycle.  The  costs  of  multiple  rule 
selection  and  testing,  shewn  in  the  profiles  of  the 
unify  procedure  in  the  preceding  chapter,  may  be  high. 

It  is  recognized  that  the  existential  quantification 
of  the  present  design  is  sufficient  to  accomplish  the 


cpd_rule 


rule 


‘  1 

S$=newcell  (CPD_R  ULE,Nil,$1) 

} 

|  cpd_rule  ELSE  rule 

{ 

$$  =  newcell  (CPD_RULE, $1 , $3)  ; 

} 

« 

rule  :  IF  cause  IMPLICATION  effect 

{ 

$$  =  nevcell  (RULE, $2, $4} ; 

} 

|  IF  cause  IMPLICATION 

£ 

$$  =  newcell  (RULE , 32 , Nil)  ; 

} 

1  IMPLICATION  effect 

£ 

$$=newcell  (RULE, Nil, $2)  ; 

} 

|  effect 

£ 

$$=newcell (RULE, Nil, $1)  ; 

} 


cause 


conditions 


session 


statement 


statement 


:  /*  empty  */ 

{ 

parsetree  =  Nil; 

} 

I 

{ 

parsetree  =  Nil; 
return  (- 1)  ; 

} 

|  statement_list 

{ 

parsetree  =  $1; 
return  (-1)  ; 

} 

9 

list  :  statement 

{ 

$$=newcell  (STA_LIST  ,Nil  ,$  1) 

} 

I  statement_list  ' ; '  statement 

$$=newcell (STA_L 1ST , $  1 , $3)  ; 

} 


cpd_r ule 

C 

$$  =  $1 ; 

} 

I  fn_def i ni ti on 


denial 


Stype 

<cell>  effect 

asserti cn 

Stype 

<cell>  arguments 

seg_bl cck 

Stype 

<cell>  unop 

binop 

Stype 

<cell>  rule_denotation 

Stype 

<cell>  variable 

self_ref 

Stype 

<cell>  f n_def inition 

Stype 

<cell>  f n_application 

%type 

<cell>  cond_expr 

cpd_expr 

/*  token  declarations  */ 

Stoken 

IDENTIFIER 

Stoken 

IF 

ELSE 

Stoken 

STR_C0N 

INT_CON 

Stoken 

IMPLICATION 

BEG_DENC 

Stoken 

NE 

LE 

Stoken 

FUNCTION 

NIL 

/*  operator  precedance 

*/ 

Sleft 

i  » 

• 

Sleft 

expression 

Sleft 

list 

Weft 

'&»  »  |  • 

Slef  t 

* 

Slef  t 

*=’  '<’  *>•  NE 

LE  GE 

Slef  t 

t  + »  » _  i 

Slef  t 

'*»  */»  ’%» 

Sstar t 

session 

*% 


expression 

primary 

constant 
f n_head 
list 
call 


END_DENO 

GE 


/*  productions  for  Omega  grammar 


tracef  un  (msg) 
char  *msg; 

{ 

printf  (" \n* **$s***  -->  M,msg); 
ECHO; 

printf  (" \n")  ; 


/*********************************************$********* 

*  * 

*  YACC  Specification  for  Omega  Parser  * 

*  * 

*******************************************************/ 


56  £ 

#  include  "tag.hM 

#  include  "defs. h" 


PTR  newcell  ()  ; 

PTR  makint(); 

PTR  makstr  ()  ; 

PTR  parsetree; 
char  *strdeno  {)  ; 

%} 

/*  type  declarations  for  parser  stack  */ 

bunion  { 

PTR  cell; 

} 

%type  <cell>  session  stateme nt_list 
Stype  <cell>  statement  cpd_rule  rule  cause 
TStype  <cell>  conditions  condition  inguiry 
^type  <cell>  constraint  transaction  transactions 
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{end_deno}  { 

} 

{ne}  { 

} 

£le}  C 

} 

(ge)  { 

} 

{delimiter}  { 

} 

{comment}  ; 


{whitespace} 


return  { END_DENO)  ; 


return  (NE) ; 


return  ( IE)  ; 


return  (GE) ; 


return  (yy  text[  0  ]) 


/*  ignore  others  */ 


%% 

stregu(s1,  s2) 
char  *s1,  *s2; 
{ 


return  (strcmp  (si ,  s2)  ==  0)  ; 


{identifier} 


if  {str equ (y ytext,  "if")) 
ret  urn  (IF)  ; 

else  if  (stregu  (yy text ,  "else") 
return  (ELSE)  ; 

else  if  (stregu  (yy  text,  "fn")) 
return  (FUNCTION)  ; 

else  if  (stregu (yy text,  "Nil")) 
return  (NIL)  ; 

else 

return  (IDENTIFIER)  ; 

} 

{int_con}  { 

return  (INT_CON)  ; 

} 

{str_con}  { 

c  =  input()  ; 

if  (c  ==  *\"')  { 

unput(c)  ; 

— yyleng ; 
yymore  ()  ; 

} 

else  { 

unput(c)  ; 
return  (STR_CON)  ; 

) 


{implication}  { 

} 


return (IMPLICATION)  ; 
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A££ENP1I  I 

LEI  AND  7 ACC  SPECIFICATIONS  FOB  OMEGA 

/** ****************************  ************************ 


*  * 

*  LEX  specification  --  * 

*  Omega  lexical  grammar  * 

*  * 


******************************************************  / 
/*  lexical  scanner  grammar  */ 


digit 

[0-9] 

lttr 

[a-zA-Z  ] 

whitespace 

[  \t  \n  ] 

identifier 

{lttr}  (({lttr}  |  {digit}  |J*(  {lttr}  1  {digit}})  * 

int_con 

{digit}  ♦ 

delimiter 

[-♦H,.;  »a()  {}*/%-&  :=<>.]!  \[  1  \] 

implication 

-> 

deno 

« 

end_deno 

» 

ne 

le 

<= 

ge 

>= 

int_con 

{digit}  + 

str_con 

\»  II  j  *  \ll 

comment 

\!  [^\n  ]*\n 

%% 

/*  recognizer  actions  for  token  classes  */ 


int  c; 
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C.  CONCLUSIONS 


This  thesis  has  described  two  prototype  implementations 
of  Omega  interpreters,  based  cn  the  model  of  a  LISP-like 
list  processing  system.  Through  these  designs,  we  have 
developed  a  complete  LL(1)/LE(1)  grammar,  and  implemented  a 
table-driven  parser  using  the  IA CC  parser  generator.  Many 
of  the  design  and  implementation  problems  encountered  are 
similar  to  the  LISP  design  issues  of  the  literature. 

The  unconventional  component  of  Omega  is  its  pattern- 
directed  set  of  active  rules.  Our  implementation  processes 
these  rules  by  a  simple  triggering  method  of  rule  indexing 
based  on  relation  identifiers.  Triggering,  along  with  the 
processing  of  multiple  rule  queues,  simulates  the  concurrent 
evaluation  of  rules  in  the  Omega  model. 

An  evaluation  of  our  interpreter’s  performance  indicates 
current  execution  speeds  are  slower  than  Franz  LISP  and 
C-Prolog.  Possible  bottlenecks  include  excessive  recursive 
calls  to  the  central  evaluation  function,  inefficiencies  in 
pattern-matching,  and  execution  penalties  in  storage  manage¬ 
ment  routines.  While  the  present  design  may  be  optimized  to 
improve  this  performance,  other  issues  are  of  more  interest 
in  future  research.  These  issues  include  alternative  repre¬ 
sentations  of  relations,  alternative  control  strategies  for 
forward  inference  rule  systems,  and  the  exploitation  of 
parallelism  in  Omega. 

Our  final  contribution  in  this  work  is  a  body  of  Omega 
programs  and  some  statistical  information  on  their  behavior. 
As  the  Omega  language  matures,  this  experience  may  help  to 
characterize  potential  extensicns  and  improvements  to  the 
language  and  its  implementation. 
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parallelism  (where  multiple  rules  for  a  goal  are  evaluated 
concurrently)  [Ref.  36:  p.  29]. 

In  Omega,  AND  parallelism  may  be  exploited  in  both 
the  antecedent  and  consequent  of  a  rule.  In  the  antecedent, 
inquiries  must  be  independent  for  concurrent  evaluation. 
Consider  the  following  rule: 

if  *R  1  (x)  ,  *R2(x),  *R3(y)  ->  R3  (x+y)  . 

The  first  two  inquiries,  R1(x)  and  R2 (x) ,  are  mutually 
dependent  on  the  variable  x.  An  evaluation  order  for  these 
inquiries  should  be  made  to  allcw  the  binding  for  the  vari¬ 
able  x  to  guide  the  relation  search.  The  third  inquiry, 
R3  (y)  ,  is  independent  of  evaluation  order.  An  AND  parallel 
strategy  should  separate  a  rule  antecedent  into  independent 
subunits  that  exploit  concurrency  where  possible. 

The  evaluation  of  actions  in  the  consequent  of  a 
rule  has  fewer  constraints.  Any  actions  separated  by  commas 
are  potentially  subject  to  concurrent  evaluation.  The 
actions  of  a  sequential  block  are,  however,  restricted  to  a 
mandatory  evaluation  order. 

The  evaluation  of  separate  rules  in  Omega  is  unord¬ 
ered;  OR  parallelism  is  the  norm  for  the  Omega  model.  A 
parallel  implementation  of  rule  evaluation  is  complicated  by 
the  shared  memory  access  that  many  rules  require.  This 
shared  access  implies  a  locking  mechanism  at  the  relation 
level,  along  with  a  deadlock-prevention  strategy. 

The  exploitation  of  parallelism  in  Omega  offers  the 
potential  for  the  resolution  of  our  present  performance 
bottlenecks.  A  parallel  architecture  that  optimizes 
pattern-matching  and  concurrent  rule  evaluation  would  yield 
substantial  performance  improvements. 
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•  The  file  is  parsed  using  the  file  command  reader, 
invoked  with  the  Do  procedure  call. 

•  Any  rule  denotations  contained  in  the  command  rules  are 
then  activated. 

This  process  requires  rule  files  to  be  reloaded  each 
time  the  interpreter  is  run.  Also,  the  current  implementa¬ 
tion  allows  rule  activation  but  not  deactivation.  These 
limitations  suggest  the  following  extensions: 

•  A  save/restore  facility.  This  facility  would  copy  and 
restore  the  virtual  memory  imaye  of  the  interpreter's 
data  segment. 

•  A  structure  editor.  There  is  currently  no  way  to  edit 
rule  denotations  once  they  are  loaded  into  the  inter¬ 
preter.  A  structure  editor  would  be  useful,  particu¬ 
larly  when  debugging. 

•  Buie  deactivation.  The  ability  to  remove  rules  from 
active  status  is  necessary  to  allow  testing  and  modifi¬ 
cation.  The  use  of  rule  names  would  simplify  this 
process. 

3-  Parallel ism  in  Omega 

The  prototypes  discussed  in  this  work  have  been 
sequential,  single- threaded  control  implementations.  An 
important  extension  to  this  work  is  the  exploration  of 
parallelism  in  Omega  rule  interpretation,  with  architectures 
tailored  for  concurrent  rule  evaluation. 

Parallelism  in  Omega  shares  similarities  with  paral¬ 
lelism  in  Prolog.  The  Prolog  literature  divides  this  paral¬ 
lelism  in  two  categories:  AND  parallelism  (where  multiple 

subgoals  in  a  rule  are  evaluated  concurrently)  ,  and  OR 


The  space  considerations  of  Chapter  VI,  as  well  as 
the  execution  statistics  of  Chapter  VII,  indicate  that  a 
garbage  collection  scheme  may  preferable  to  reference 
counting-  The  implementation  of  an  efficient  compacting 
garbage  collector  can  provide  significant  performance 
improvements. 

A  useful  extension  to  our  implementation  would  be  a 
flexible  debugger.  He  currently  use  a  trace  facility  that 
provides  a  display  of  rule  execution.  While  this  facility 
is  useful,  the  information  provided  is  not  specific  enough. 
The  following  debugging  features  would  be  helpful: 

•  Specification  of  trace  and  break  points  by  relation 
name.  When  a  tuple  is  added  or  removed  from  a  relation, 
the  debugger  may  be  invoked  and  the  bindings  of  vari¬ 
ables  available  for  examination. 

•  Specification  of  trace  and  break  points  for  specific 
rules.  This  facility  is  similar  to  the  preceding  one, 
but  only  certain  rules  are  monitored.  Note  that  the 
lack  of  names  for  individual  rules  makes  this  feature 
difficult  to  implement. 

•  Debugger  invocation  on  error  conditions.  As  in  the  LISP 
prototype,  error  conditions  result  in  an  error  message 
and  a  return  to  the  interpreter's  top  level.  The  imple¬ 
mentation  of  a  debugger  would  allow  a  more  sophisticated 
response. 

Our  present  method  for  rule  creation  and  modifica¬ 
tion  should  be  extended.  Currently,  the  following  steps  are 
used  to  create  rules: 

•  Command  rules  are  entered  into  a  file  using  a  standard 
text  editor.  The  vi  t  .  cedure  call  is  provided  in  Omega 
to  allow  ready  access  to  the  UNIX  editor  of  the  same 
name  [Ref.  26]. 
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technique  is  to  provide  a  hashed  index  structure  for 
tuples  within  a  relation,  possibly  using  a  user- 
specified  key  or  arbitrarily  using  the  first  tuple 
member  as  a  key.  An  indexed  relation  structure  would 
have  little  impact  on  most  of  the  benchmarks  of  the 
preceding  chapter  (except  the  pattern-matching  test) 
because  of  the  small  relation  sizes.  A  substantial 

performance  improvement  for  inquiries  on  larger  rela¬ 
tions  may  be  realized. 

•  A  relational  DBMS  implementation  of  relations.  The 
current  design  can  be  extended  to  include  a  query  and 
response  translation  interface  with  a  concurrently 
executing  DBMS.  The  interface  could  be  organized  around 
object  identifier  recognition,  as  system  objects  are 
currently  handled.  The  tag  field  of  DBMS-supported 
objects  could  be  assigned  a  unique  value  to  route  these 

objects  to  the  DBMS  interface  instead  of  the  normal 

relation  management  routines. 

Control  strategies  for  rule  selection  and  test 
remain  an  open  subject  in  this  work.  Our  two-level  trig¬ 
gering  strategy,  discussed  in  Chapter  7,  was  selected  as  a 
compromise  implementation  that  provides  a  reasonable  level 
of  rule  selection  precision  under  a  programmer's  control. 
Full  indexing  of  rules — triggering  on  all  the  relations  in 
the  rule  antecedent-- was  not  attempted.  The  performance  of 
full  indexing  compared  to  two-level  triggering  is  a  poten¬ 
tial  point  for  additional  study. 

The  control  strategy  of  Omega,  like  Prolog,  is 
"hard-wired”  into  the  interpreter  design.  The  designs  of 
several  ether  rule-based  systems  have  taken  a  more  flexible 
approach:  meta-rules  dictate  control  strategies  [Ref.  35]. 

The  idea  of  integrating  rule-based  control  strategies  into 
Omega  would  be  an  interesting  extension  to  the  language  and 
its  interpretation. 
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intended  function  of  the  CopyRel  rules  and  similar  applica¬ 
tions.  The  advantages  of  universal  quantification  must  be 
weighed  against  the  added  complexity  to  the  lanyuage. 

It  would  be  useful  to  be  able  to  reference  rules  by 
name.  Ihe  rule  forms  the  basic  computational  unit  in  the 
language,  yet  may  net  be  referenced  explicitly;  the  only 
named  reference  for  a  rule  is  its  source  rule  denotation. 
If  the  denotation  is  large,  its  name  is  not  a  selective 
description.  If  a  single  rule  is  to  be  manipulated,  perhaps 
by  a  structure  editor,  the  entire  denotation  must  be 
accessed.  A  similar  problem  is  experienced  with  activating 
and  deactivating  rule  denotations. 

2.  Extensions  to  the  Present  Interpreter  Design 

Our  present  implementation  includes  the  majority  of 
Omega  language  features  described  in  [Ref.  14].  Several 
possible  extensions  to  the  present  implementation  are  of 
interest. 

The  class  mechanism  described  in  Chapters  II  and  IV 
is  not  currently  implemented.  The  present  system  provides  a 
single  directory,  root,  freguently  referenced  in  our  exam¬ 
ples.  The  class  and  directory  structures,  with  rules 
indexed  on  relation  objects,  provide  the  inheritance  mecha¬ 
nism  for  the  language.  The  implementation  of  classes  as 
binding  lookup  paths  will  allow  a  more  thorough  exploration 
of  the  object-oriented  nature  of  Omega  than  has  been 
provided  in  this  work. 

Both  the  LISP  prototype  and  the  current  prototype 
use  a  simple  linked-list  relation  structure.  There  are  two 
alternate  representations  that  are  of  immediate  interest: 

•  Hashed  indexing  of  relation  lists.  Relations  lists  are 
currently  selected  via  hashed  access  of  the  object 
table.  A  performance-enhancing  extension  to  this 
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} 


conditions  :  condition 

{ 

$$=newcell  (CONDS  , Nil, $  1) ; 

} 

|  constraint 

{ 

$$=newcell  (CONDS , Nil ,$ 1 )  ; 

} 

|  conditions  ' condition 

{ 

$$=newcell  (CONDS  ,  $1,  $3) 

} 

|  conditions  ' , 1  constraint 

{ 

$$=newcell  (CONDS,  $1,  $3) 

} 

* 

condition  :  •*'  inquiry 

{ 

$$=newceil (CANC, $2, Nil)  ; 

} 

|  inguiry 

{ 

$$=newcell  (ABST, $2, Nil)  ; 

} 

|  inguiry 
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{ 

$$  =  newcell (PRES,  $  1 , Nil)  ; 

3 


inquiry 


i 


constraint 


effect 


transactions 


I 


transaction 


primary  1  ('  arguments  •) 

£ 

$$=newcell  (INQY,  $1,$ 3)  ; 

} 


expression 

£ 

S$=newcell  (CONSTR,  $  1 , Nil) 

} 

transactions 

( 

$$  =  $1; 

} 

transac  tion 

£ 

$$= newcell  (TRANS , Nil , $  1) . 

} 

transactions  transaction 

£ 

$$=  newcell (TRAN 5,$1,$3)  ; 

} 

assertion 

£ 

$$  =  $1; 

} 

denial 


! 


assertion 


denial 


fn  definition 


fn  head 


{ 

$$  =  J1; 

} 

express  ion 

£ 

$$  =  $1; 

} 

seg_block 

£ 

$$  =  $1; 

} 

primary  * ('  arguments  ')  • 

£ 

$$=newcell  (ASSEE ?, $  1 , $3) 

} 

' -»•  primary  *('  arguments  ’)  ' 

£ 

$$=newcell  (DENY,  $2, $4)  ; 

} 

FUNCTION  fn_head  '  cpd_expr 

£ 

$$=newceil (FN,$2 ,$4)  ; 

} 

’  [ ’  arg  uments  '  ]  ' 

£ 

$$= newcell (FSDCL , Nil ,  $2) 

} 

primary  '['  arguments  *]• 

£ 
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$$= new  cell  (FNDCL,$1,$3)  ; 

) 


arguments  :  /*  empty  */ 

£ 

$$  =  Nil; 

} 

|  list 

£ 

$$  =  $1; 

} 

|  expression  expression 

£ 

S$=newcell  (CONS,  $1,$3)  ; 

} 


list  :  expression 

£ 

3$=newcell  (LIST,  Nil, $1)  ; 

} 

1  list  ' , 1  expression 

{ 

$$=newcell  (LIST,  $1 , $3)  ; 

} 


{'  statement_list  *}  1 

£ 

$$=newcell  (SE2_3 LK, $ 2 , N il) 


seq_block 


1 


1  *  {'  statement_list  '}• 

{ 

$$=newcell  (SEQ_BLK,  $2,  Nil) ; 

I 

} 

t 

expression  :  primary 

{ 

$$  =  $1; 

} 

1  constant 

{ 

$$  =  $1; 

} 

|  call 

{  ' 

$$  =  $1; 

} 

|  fn_application 

{  » 

$$  =  $1; 

} 

|  rule_denotation 

{  r 

$$  =  $1; 

} 

I  unop 

{  ' 

$$  =  31; 

}  •: 

|  binop 

l  L 

$$  =  $1 ; 

} 

I  ’  ('  cpd_expr  ’ )  ’ 

l 


i 
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I 


I 


I 


fn_apflication 


call 


rule  denotation  : 


£ 

$  $  =  j>  2  j 

} 

•[  •  list  •  ]• 

£ 

$$  =  $2; 

} 

'[  '  expression  expression  '  ]* 

£ 

S$=newcell (CONS,  $2, $4)  ; 

} 

*C  *  •]• 

£ 

$$  =  Nil; 

} 


primary  arguments  *  ]' 

£ 

$$=newcell  (APL, $  1 , $3) ; 

} 

primary  1  arguments  '}  * 

£ 

$$=newcell  (CALL,  $1,$3)  ; 

} 

BEG_DE  NO  statement_list  END_DENO 

£ 

$$=newcell  (DENO,  $2,  Nil)  ; 

} 

BEG_DEN C  statement_list  END_DENO 
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J3=newcell  (DENO, 32, Nil)  ; 

} 


unop  :  *+*  expression  Spree  * *' 

{ 

$$  =  $2; 

] 

|  «-«  expression  Spree  ' ** 

£ 

$$=newcell  (UNMINUS,$2,Nil)  ; 

} 

|  *-•*  expression 

£ 

$$=new cell  (N0T,$2,Nil)  ; 

} 

t 

binop  :  expression  1 +'  expression 

£ 

$$=nevcell  (PLUS,  $1 ,  $3)  ; 

) 

|  expression  expression 

£ 

$$=nevceil  (MINUS  ,$  1 , 33)  ; 

} 

|  expression  ***  expression 

£ 

$$=  newcell  (MULT,  $1,  S3)  ; 

} 

|  expression  '/’  expression 

£ 

S$= newcell  (DIV,$1,$3)  ; 

} 

|  expression  expression 

£ 


156 


S$= newcell  (MOD,  $  1 ,  Z3)  ; 

3 

expression  ’='  expression 

{ 

$$=n ewcell  (EQU,$1,$3)  ; 

3 

expression  '<•  expression 

£ 

$$=newcell (LT,$1 ,$3) ; 

3 

expression  •>*  expression 

{ 

$$=n ewcell  (GT,S1  ,$3)  ; 

3 

expression  NE  expression 

£ 

$$=newcell  (NEQ#$1,$3)  ; 

3 

expression  IE  expression 

£ 

$$=newcell  (LEQ,  i  1 ,  $3)  ; 

3 

expression  GE  expression 

£ 

$$=n ewcell  (GEQ,$1,$3)  ; 

3 

expression  ’5’  expression 

£ 

$$=n ewcell  (AND,$1 ,$3)  ; 

3 

expression  • | *  expression 

£ 

$$  =  newcell  (0R,$1 ,$3)  ; 

3 
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primary  :  variable 

{ 

$$  =  $1; 

3 

|  self_ref 

{ 

$$  =  $1; 

3 

t 

self_ref  :  '3'  variable 

{ 

$$=newcell  (SELF_REF  ,$2,  Nil)  ; 

3 


variable  :  IDENTIFIER 

l 

parsetree  =  makstr (yytext) ; 
$$=nevcell  (VAR, Nil,  parsetree)  ; 

3 

9 

constant  :  STR_CON 

{ 

$$  =  makstr (strdeno  (yytext) )  ; 

3 

|  INT_CON 

l 

$$  =  makint (atoi (yytext) )  ; 

3 

|  NIL 

( 

$$  =  Nil; 

15  8 


} 


cpd_expr  :  cond_expr 

{ 

$$=newcell  (CPD_R 'JLE  ,Nil,  $  1)  ; 

} 

I  c pd_expr  ELSE  cond_expr 

C 

$$=n ewcell  (CPD_RULE,  $1 , $3)  ; 

} 

9 

cond_expr  :  expression 

{ 

$$=newcell  (RULE,  Nil,  $1)  ; 

} 

|  IF  constraint  IMPLICATION  expression 

{ 

$$=newcell  (RJLE,i2,S4)  ; 

} 
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AS/Q 


/*  user  defined  functions  */ 

#  include  "lex.yy.c" 

/*  string  denotation  routine 

Lexical  scanner  returns  string  constants 
with  "  delimiters  included. 

Denotation  routine  simply  removes  the  extra  "s. 
- v 

char  *strdeno(s2) 
char  *s2  ; 
l 

char  *s  1 ; 
si  =  s2  +  1 ; 

*  (si  +  (strlen  (si)  - 1)  )  =  '\0'; 
return  (si); 

} 

/*  error  handler 

Prints  error  message  and  line  number  where  error  occurred. 
No  attempt  made  to  recover  from  errors. 

- v 

yy error  (msg) 
char  *msg; 

printf (”%s  :  ",  msg)  ; 

printf  ("line  IfcdXn",  yylineno)  ; 

) 
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APPENDIX  B 

BUILT-IN  FUNCTIONS  AND  PROCEDURES 

Built-in  Functions 
A.  Infix  operators  -- 
op  type 


+ 

* 

% 

/ 

< 

> 

<= 

>= 

-l= 

& 

I 


str  x  str  ->  str  (concatenation) 

int  x  int  ->  int 

It 

If 

11  (modulus) 

it 

int  x  int  ->  Bool 

it 

ii 


n 

any  x  any  ->  Bool 
any  x  any  ->  Bool 
Bool  x  Bcol  ->  Bool 
Bool  x  Bcol  ->  Bool 


Unary  operators  ; 

Int  ->  Int 

-»  Bool  ->  Bool 


B.  System  defined  functions  : 

Islnt[item]  —  Returns  TRUE  if  item 

is  an  integer. 


IsS  tr[  item  ] 


Returns  TRUE  if  item 


is  a  string. 


Islist[ item  ] 

—  Returns  TRUE  if  item 

is  a  list. 

IsOb  j[  item  ] 

—  Returns  TRUE  if  item 

is  an  object. 

IsRel[  item  ] 

—  Returns  TRUE  if  item 

is  a  relation  object. 

int_str[ int  ] 

—  Integer  to  string  conversion. 

first[ list  ] 

—  CAR.  Returns  the  first  member 

of  a  list. 

rest[  list  ] 

—  CDR.  Returns  all  members  of 

a  list  after  the  first  member. 

cons[  x,  1] 

--  Returns  a  new  list  with  x  as  its 

first  member  and  1  as  the  rest  of 
the  list.  The  notation  [x:l] 
does  the  same  thing. 


objval[ object  ]  —  Returns  the  value  bound  to  an 

object. 

The  following  objects  have  bound  values  : 

rela  tions 

functions 

rule  denotations 

directories 

Tag[form]  —  Returns  a  string  representing  the 

tag  of  form. 
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I. 


Built-in  Procedures 


A.  General  usage: 

do  {"filename"}  --  Executes  rules  from  file. 

activate  {name}  --  Activate  rule  denotation. 

decode  {form}  --  Post  order  dump  of  nodes. 

displa y {form}  --  Pretty  printer. 

displayn  {f orm}  --  Pretty  printer.  Ends 

with  a  newline. 

" name" , def } - -  Make  a  directory  entry. 

--  Toggle  the  trace  function. 

--  End  session. 

Same  as  Cntl-D. 

newobj{}  --  Generate  a  new  object. 

newrel  {}  --  Generate  a  new  relation. 

purge {relati on_name}  --  Empty  a  relation. 

B.  UNIX  system  hooks: 

vi{"file"}  --  Invoke  the  VI  text  editor 

system {" command"}  --  Pass  a  command  to  the 

UNIX  shell. 


aef ine {dir , 
trace  {} 
exit  {} 


shell  {} 


--  Spawn  a  temporary 
UNIX  shell. 


remove  (?,  [  ],  £  ])  . 
reaove(?#  [I|Is],  [I|Nis]) 
not  (0  is  I  mod  P)  , 
remove  (P  ,  Is  ,  Nis)  . 
remove(P,  [I|Is],  Nis) 

0  is  I  mod  ? ,  remove(P,  Is,  Nis). 

sTest  : - 

system  (" date")  , 
primes  (350,  Ps)  , 
system  (" date")  , 
print  (Ps)  . 


sieve  benchmark  —  Franz  LISP 


(defur  iota  (nl  n2) 

(cond  ((greaterp  nl  n2)  nil) 

(t  (cons  nl  (iota  (addl  nl)  n2))))) 

(defun  purgeMults  (x  1) 

(cond  ((null  1)  nil) 

((zerop  (mod  (car  1)  x)  )  (purgedults  x  (cdr  1)  )  ) 
(t  (cons  (car  1)  (purgeMults  x  (cdr  1)))))) 


(defun  primes  (n) 

(primesAux  (iota  2  nj  )  ) 

(defun  primesAux  (1) 

(cond  (  (null  1)  nil) 

(t  (cons  (car  1) 

(primes  A  ux 

(pur geMults 
(car  1) 

(cdr  1)  )))))) 


I 


else  [  first[  1  ];  Purgeilul  ts[  x,  rest£l]]]. 

define  {root,  "SieveR ules" , 

« 

if  *Primes(a,  n)  -> 

PrimesAux (a,  iota£2,  n],  Nil); 

if  *PrimesAux  (a,  Nil,  1)  -> 
a  (reverse£  1  ]) 

else  if  *PrimesAux  (a,£x:11  ],  12)  -> 

PrimesAux(a,  FurgeMults £x,  11],  £x:12]); 

if  *sTest  (a)  ->  £ 

system  {•'date'1}  ; 

Primes  £350}  ; 
system  {"date"}  ; 
a ("OK")  ; 

] ; 

»}  • 

activat  e  [SieveSules}  . 

/* 

Sieve  benchmark  —  Prolog 

- V 

primes  (Limit,  Ps) 

iota(2.  Limit,  Is), 
sift(Is,  Ps). 

iota  (Lo,  Hi,  £Lo|Kest])  i- 

Lo  =<  Hi,  M  is  Lo+1,  iota(M,  Hi,  Rest). 

iota  _,  £  ])  . 

sift  (£  :,  £  ]). 

sift  (£l|ls],  [IJPs  ]) 

remove(I,  Is,  New),  sift(New,  Ps)  . 
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;  the  benchmark  driver  -- 
;  (fact  15)  executed  n  times 
(defun  driver  (n) 

(cond  ((equal  n  0)  "OK") 

(t  (fact  15) 

(dri  ver  (-  n  1) )  ) )  ) 

;  the  CSH  date  function  provides  a  crude 
;  timer  to  the  nearest  second. 

(defun  factTest  (n) 

(exec  date) 

(driver  n) 

(exec  date)) 


************************************************** 
*  * 

*  Prime  Number  Sieve  * 

*  * 

*  * 

ft******************************:***#*************** 


sieve  benchmark  --  Omega 


define  {root,  "Primes",  newrel  {}  }. 
definefroot,  "PrimesAux",  newrel{j). 
define  {root,  "sTest",  newrel  {}}  . 

fn  PurgeMults[  x,  1]  : 

if  1=  Nil  ->Nil 

else  if  first[l]  %  x  =  C  -> 

Purye«ults[  x,  rest[l]j 
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I 


syst  em  ("date")  ; 

Driver  {n}  ; 
system  ("date")  ; 

} ; 

»}  • 

I  activate  the  rules 
activate  {DriverB  ules} . 

/* 

factorial  benchmark  —  Prolog 

- V 

fact  (N,  1)  N  =<  0. 

fact  (N,  F) 

N  >=  0,  fact  (N- 1 ,  M)  ,  F  is  M  *  N. 

driver  (0)  . 
driver(N) 

H  >  0,  fact  (15,  X),  M  is  N-1,  driver  (M)  . 

factTest  (N) 

system  ("date") , 
driver  (N)  , 
system  ("date")  . 


;  Factorial  benchmark  --  Franz  LISP 


(defun  fact  (n) 

(cond  ((lessp  n  0)  1) 

(  (zerop  n)  1) 

(t  (*  n  (fact  (-  n  1)  )  ))  )  ) 
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************************************************** 


*  * 

*  Factorial  * 

*  * 

*  * 


************************************************** 


factorial  benchmark  —  Cmega 


fn  £act[n]  : 

if  n  <=  0  ->  1 
else  n  *  fact[n-1]. 

!  driver  rules 

define{root,  "Driver",  newrel  {}  }. 
define{root,  "factTest",  newrel  {}}  . 
define  {root,  "Driver Eules", 

«  if  *Driver(a,  n)  ->  ( 

if  n  <=  0  ->  a  ( "OK") 
else  ->  { 

fact[  15  ]; 

Driver(a,  n-1} 

} 

}; 

!  the  CSH  date  function  provides  a  timer 
!  times  given  to  the  nearest  second 

if  *factTest  {a,  n)  ->  { 

display {"Omega  factorial:  "}  ; 
display  {n}  ; 
displayn  {"  calls"}; 
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(defun  genDat  (nl  n2) 

(prog  (i  1) 

(setg  il  nl) 

LOOP 

(cond  {(greaterp  il  n2) 

(return) ) 

(t  (setg  rl  (cons  il  rl)) 

(setg  r2  (cons  (plus  il  n2)  r 2)  ) 
(setg  il  (addl  il)) 

(go  LOOP))) )  ) 

(defun  match  () 

(prog  £  1 1  t2) 

(setg  tl  rl) 

LOOP  1 

(setg  t2  r2) 

LOOP  2 

(cond  ((null  t2) 

(cond  ((null  1 1)  (return  nil)) 

(t  (setg  tl  (cdr  tl ) ) 

(go  L COP  1 )  ) )  ) 

((egual  (car  tl)  (car  t2)) 

(return  (car  1 1)  ) ) 

(t  (setg  t2  (cdr  t2)  ) 

(go  LOOP 2) ) )  )) 

(defun  mTest  () 

(setg  rl  (list  9999)) 

(setg  r2  (list  9999)) 

(genDat  1  1000) 

(exec  date) 

(match) 

(exec  date)  ) 


system  {"  date"}  ; 
if  Rl  (x)  ,  R2  (x)  ->  { 

system  (’date")  ; 
displayn  {x}  ; 

}; 

a  ("OK")  ; 

} 

»}  • 

!  activate  the  rules 
activate  {MatchRules}  . 


/* 

PROLOG  pattern  matching  benchmark 
- */ 

rl  (9999)  . 
r2  (9999)  . 

genDat  (La,  Hi) 

Lo  <  Hi, 

12  is  Lo  *  Hi, 
asserta  (r  1  (Lo) )  , 
asserta  (r2  (12) )  , 

Lonext  is  Lo  *  1, 
genDat (Lonex t.  Hi). 
genDat  ( Hi,  Hi)  . 

mTest  (X) 

genDat  (1  ,  1000)  , 
system  ("date")  , 
rl  (X)  ,  r 2  (X)  , 
system  ("date") . 


pattern  matching  benchmark  —  Franz  LISP 
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D 

COMPARATIVE  APPLICATIONS:  OMEGA,  LISP,  AND  PROLOG 


************************************************** 


*  * 

*  Pattern  Matching  Tests  * 

*  * 

*  * 


************************************************** 


pattern  matching  benchmark  —  Omega 


define  {root , 
define {root, 
define {root, 
define  {root. 


"R 1 ",  newrel  {}  }  . 
"R2",  newrel  {}  }  . 
"genDat",  newrel{)}. 
"mTest",  newrel  {}}. 


define{root,  "MatchR ules" , 

« 


!  the  data  generating  rules 

if  *genDat(a,  nl,  n2',  nl  >  n2  -> 
a  ("OK”) 

else  if  *genDat(a,  nl,  n2)  ->  { 

R1  (nl)  ; 

R2(n1  +  n2)  ; 
genDat  (a,  n 1  +  1,  n2)  ; 

}; 

if  *mTest(a)  ->  { 

Rl  (9999)  ;  R2  (9999)  ; 
genDat  {1  ,  1000}  ; 
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newrei  {} }  . 


w 


define  {root,  " AssertTuple", 

define  {root,  " Asser tListEules" , 

« 

if  *Assertlist  (a:[r:L])  ,  IsRel[  a],  IsRel[  r  ]  -> 

AssertAux(a,  r,  L) 

else  if  *AssertList  (a:L)  -> 

displayn  {"Usage  :  Asser  t  [Relname,  ListOf  Tuples}  "}  , 
a  (Nil)  ; 

if  *AssertAux (a,  r.  Nil)  -> 
a  ("OK") 

else  if  *AssertAux (a,  r,  £x:l])  -> 

AssertTuple  {r,  x]  , 

Assert  Aux  (a,  r,  1); 

if  ^AssertTuple  (a,  r,  x)  ,  -«IsList[x]  -> 

displayn  {"Error  in  Assert  --  tuple  not  a  list",  x} 

else  if  *AssertTuple  (a,  r.  Nil)  -> 
a  (Nil) 

else  if  *AssertTuple  (a,  r,  [x:l^) 
r  (x:l)  , 
a  (r )  ; 

»}. 

activate  {Asser tListEules] . 
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CopyRel  (x,  temp}, 
DumpDisplay (a,  x,  temp); 


if  *DumpDisplay  (a,  name,  K)  ,  *R(x:y)  -> 
display {name} , 
display  ["  ("}  , 
display  £x :y}  , 
displayn  £")  .  "}  , 

DumpDisplay ( a,  name,  R) 

else  if  *DumpDisplay  (a,  name,  R)  -> 

a  ("")  ; 

!  Pretty  print  objects  ... 

!  Functions  require  a  bit  of  set  up 

if  *PpOb  j  {a,  name,  def)  ,  Tag[ def ]="FN"  -> 
display  {"fn  "}  , 
display {name} , 
displayn  £def } , 
a 

!  otherwise,  just  display  def  (might  be  Nil) 

else  if  *PpObj(a,  name,  def)  -> 
displayn {def}  ; 


»  }• 

activate  {PpRules} . 


!  assert  list  procedures 

!  allows  one  to  assert  multiple  tuples  to  a  relation 

!  Usage  is  Assert  {relnam  e ,  [tuple],  [tuple],  ...} 

define{root,  " AssertList",  newrelQ}. 
define{root,  "Assert Aux",  aewrel[j)  . 
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define  {root,  "Pp",  newrel{}}. 
define  {root,  "PpAux",  newrel{}}. 
define  {root,  "PpRel",  newrel{}}. 
define  {root,  "PpObj",  newrel{}}. 
define  {root,  "DumpDi  splay ",  newrel{}} 


the  rules  .  .  . 

define {root,  "PpRules", 


!  single  member  is  a  gocf  by  the  user 
if  *Pp (a  :L)  ,  -<IsRel[a]  -> 

displayn  {"Osage  :  Pp{x1,  x2, 

if  *Pp  (a  :Nil )  -> 
a  ("OK") 

else  if  *Pp(a:[x:L])  -> 

PpAux  {x}  , 

Pp  (a  :L)  ; 

J  Is  it  a  relation  ? 
if  *PpAux(a,  x)  ,  IsRel{x]  -> 

PpRel  {x,  newrel  0  }  / 
a  ("") 

!  or  other  type  of  object  ? 
else  if  *PpAux(a,  x)  ,  IsObj[x]  -> 
PpObj  (a,  x,  objval[xJ), 
a("") 

!  otherwise  just  display  it 
else  if  *PpAux(a,  x)  -> 
displayn  {x}  , 
a  { "  " )  ; 

if  *PpRel(a,  x,  temp)  -> 
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if  *Bugs  (a)  -> 

displayn  {"Describe  the  buy.  End  with  Cntrl-D 
system  ["mail  -s  'Bug  Report'  mcarthur"}, 
a  ("OK") 

»}. 

define[root,  "Bugs",  newrel{}}. 
activate  {BugRules}  . 

displayn  {"To  report  a  bug,  enter  Bugs  {}  .  "}  . 


!  CopyRel  —  Copy  from  one  relation  to  another 

!  Usage  is  CopyRel  [R1,  R2}. 


define  {root,  "CopyRel",  newrel  [}}  . 

define  [root,  "Copy RelRules" , 

« 

if  CopyRel(a,  rl,  r2),  r1(x:y),  -*r2(x:y)  -> 
r2  (x: y) 

else  if  *Cot.yRel(a,  rl,  r2)  -> 

a  ("OK")  ; 


activate  {CopyRelRules}. 

!  pp  -  A  pretty  printer  f cr  objects. 


These  rules  are  required  because  the  standard  pretty 
printer  -  display  -  doesn't  do  lookups  on  objects. 

define  the  relations.... 


if  11  =  Nil  |  12  =  Nil  ->  Nil 
else  cons[  [  f  irst£  11  ],  first£12]], 

pairlist[  rest£l  1  ] ,  rest£12]]]. 

fn  append[11,  12  ]  : 

if  11  =  Nil  ->  12 
else  if  12  =  Nil  ->  11 

else  cons[  f  irst[  11  ],  append£  rest[  1 1  ],  12]]. 

fn  iota£  n1,  n2  ]  : 

if  nl  >  n2  ->  Nil 

else  cons[  nl,  iota[n1+1,  n2]]. 

fn  length[l]  : 

if  l=Nil  ->  0 

else  1  +  len  gth£  rest[  1  ]  ]. 

fn  ith[  I,  i  ]  : 

if  i<= 1  ->  1 

else  if  l=Nil  ->  Nil 

else  ith[rest[l],  i-1]. 

t*****^*  ************* **********  ************ 

!  Utilities  --  ! 

!  This  file  contains  a  set  of  utility  ! 

!  rules  that  are  automatically  loaded  ! 

I  at  system  boot.  ! 


!  System  Help  function 

define  (root/  "help",  newrel  (] }  . 
define£root,  "Helplib",  newrel{}}. 

HelpLib  ("?",  "/work/mcar  thur/common/summa ry .  help") 


16  5 


appendix  c 

UTILITY  FUNCTIONS  AND  RULES 

!  Function  library 

!  A  dummy  forward  declaration  is  used  for  reverseAux 

!  due  to  single  pass  static  scoping. 

fn  re  verseAux£  x  ]  :  Nil. 

fn  reverse' 1]  :  reverseAux[  1 ,  Nil]. 

fn  reverseAux[ 11 ,  12  ]  : 

if  11  =  Nil  ->  12 
else 

reverse Aux[  rest[l  1  ] ,  cons[  first[  11  ],  12]]. 

fn  map[f#  1]  : 

if  1  =  Nil  ->  1 
else 

cons£  f[  first[  1  ]  j/  map[  f ,  rest[  1  ]  ]  ]. 

fn  member[x,  1]  : 

if  1  =  Nil  ->  Nil 

else  if  x  =  first[l]  ->  1 

else  member^ x,  rest£l]]. 

fn  assoc[x,  1]  : 

if  1  =  Nil  ->  Nil 

else  if  -i  lsList[  f  irst£  1  ]  ]  |  first[l]  =  Nil 

->  assoc[  x,  rest[l]] 
else  if  x  =  f irst[f  irst[l  ]]  ->  firsti.1] 
else  assoc[  x,  rest[l]]. 

fn  pairlist[11,  12]  : 

’  6  4 


{defun  sTest  () 
{exec  date) 
{primes  350) 
(exec  date)) 


*************************************** :*********** 


*  * 

*  Quicksort  * 

*  * 

*  * 


************************************************** 


Quicksort  benchmark  —  Cmega 


fn  iotaR[n1,  n2]  : 

if  nl  >  n2  ->  Nil 

else  [  n2  :  iotaR[  nl ,  n2-1']. 

define{root,  "Qsort",  newrel  [}}  . 

define  { root ,  "QsortAux",  newrel  {}}. 

define  [root,  "qTest"  ,  newrel  {}}  . 

define  {root,  "Qsor  tRules", 

I  Quick  Sort 

if  *Qsort(a,  Nil)  -> 
a  (Nil)  ; 

if  *Qsort(a,  [ x:L ])  -> 

QsortAux  (a,  x,  L,  Nil,  Nil)  ; 
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if 

♦QsortAux  (a , 

x.  Nil,  LI, 

L  2) 

-> 

a  (append[  Qsort  (LI) , 

[x: 

Qsort  (L2}  ] 

])  ; 

if 

♦QsortAux  (a , 

x,  [  y :L  1  ], 

L2, 

13) 

A 

1 

if  y  <= 

x  -> 

QsortAux (a. 

x. 

11/ 

L  y: L2  ] 

,  L3) 

else 

} ; 

QsortAux (a. 

X, 

11/ 

L2,  [  Y 

:  L3  ]) 

if 

♦gTest  (a,  n) 

->  { 

system  [" 

date"}  ; 

Qsort (iotaE[  1 ,  n  ]}  ; 
system  £" date"}  ; 
a  ("OK")  ; 

}; 

»}  - 

activate  {QsortBules}  . 


/*  Quicksort  Benchmark  —  Erolog 


*/ 


gsort  (£H|T]/S)  : - 

split (H,T,A,B) , 
gsort  ( A  ,  A 1)  , 
gsort (B  ,  B1 )  , 
append  (A  1,[  H|B1  ],  S)  . 
gsort  (£  ],  [  ])  . 

split  (H,[A|  X],[A|Y],Z) 

A  <  H, 

split (H ,X, Y,  Z) . 
split  (H/[A|  X],  Y,[A|  Z  ]) 

H  <  A, 

split  (H,X,Y,  Z) . 

split  (_,[  hi  hi  ])  - 
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append  {[  ],1,L)  . 
append{(HJTJ,L,[HJVj) 
append (T  ,L ,  V) . 

iotaR  (lo,  Hi,  [Hi]  Rest]) 

Lo  =<  Hi,  M  is  Hi-1,  iotaR(Lo,  M,  Rest) 
iotaR  [  ])  . 

gTest  (N)  :  - 

system  ("date")  , 
iotaR  (1,  N  ,  L), 
gsort (L ,  S) , 
system  ("date"), 
print (S)  . 


;  Quicksort  Benchmark  —  Franz  LISP 


(defun  gsort(l) 

(cond  ((null  1)  nil) 

(t  (setg  s  (split  (car  1)  (cdr  1) ) ) 

(append  (gsort  (car  s) ) 

(cons  (car  1)  (gsort  (cadr  s)  )))))) 

(defun  split  (x  1) 

(prog  (s) 

(cond  ((null  1)  (return  (list  nil  nil)))) 

(setg  s  (split  x  (cdr  1))) 

(cond  ( (lessp  (car  1)  x) 

(return  (list  (cor.s  (car  1)  (car  s)  )  (cadr  s)))) 
(t 

(return  (list  (car  s) 
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{cons  (car  1)  (cadr  s) )))))) ) 


(defun  iotaR  (nl  n2) 

(cond  ((greaterp  nl  n2)  nil) 

(t  (cons  n2  (iotaR  nl  (subl  n2)))))) 

(defun  glest  (n) 

(exec  date) 

(gsort  (iotaR  1  n)  ) 

(exec  date)) 


************************************************** 


*  * 

*  Missionaries  and  Cannibals:  * 

*  A  State  Search  Problem  * 

*  * 

*  * 


******************************************  ******  ** 


I  Missionaries  and  Cannibals  --  Omega 

!  Generate  and  test  search  strategy 

1 _  _  _ _ ...  .  . . .  .  .. 


define(root,  "me",  newrel{}}. 
define{root,  "misCan",  newrel{}}. 
define{root,  "PpL",  newrel{}}. 

define  {  root,  "misCanRules" ,  > 

« 

if  *mc  ( nM,  nC)  -> 

misCan ( 1 ,nM, nC, nM, nC, 0, 0,  Nil)  ; 
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if  mis  Can  (s,nM,nC,0,0,nf!,nC,path) 

->  { 

purg  e  [misCan}  ; 

PpL  {[  [s, 0,0  ,  nM,  nC  ]:  path  ]}  ; 
displayn  {"Finis  "} 

} 

else  if  *misCan (s, nM, nC,mL,cL,mR,cR,path) , 

{mL  >=  0  &  ml  <=  nH  S 

cL  >=  0  &  cl  <=  nC  & 

mR  >=  0  &  mR  <=  nH  & 

cR  ^ 11  0  &  cR  ^ ~  nC  & 

(mL  >=  cL  |  ml  =  0)  & 

(mR  >=  cR  |  mR  =  0)  )  , 
imemter[  [s,mL,cL,mR,cR],pat’  ] 

-> 

misCan  (  (0-s)  ,nM,nC,mL-s,cL,mR+s,cR, 
£,mL,cL,mR,cR  :path  ),] 
misCan  (  (0-s)  , nM, nC,  mL  , cL-s,  mR,cR+s, 
s,mL,cL,mR,cR  :path  ),] 
misCan  (  (0-s)  ,nM,nC,mL,cL-2*s,mR,cR+2*s 
s, mL, cL, mR, cR  :path  ),] 
misCan  (  (0-s)  ,nM,nC,mL-2*s,cL,mR+2*s,cR 
s,  mL,  cL,mR,  cR  :path  ),] 
misCan  (  (0-s)  ,nM,nC,  mL-s,cL-s,  mR  +  s,  cR  +s 
s, mL, cL, mR, cR  :path  )  ] 

else  if  *misCan  (s,nM  ,nC  ,mL,  cL,  mR,  cR,  path)  ->; 

!  a  small  pretty  printer  for  the  output  list 

if  *PpL  (a.  Nil)  -> 

else  if  *P pL  (a,  [x:L])  ->  { 

PpL  {1}  ; 
displayn  {x}  ; 

} 

»  }• 
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activate  {  misCanSules  }. 


/* 

Missionaries  and  Cannibals  --  Prolog 

- */ 

mc(Nm,Nc)  misCa  n  ( -1 ,  Nm,  Nc ,  0 , 0,  Nm ,  Nc,  [  ])  . 

misCan  (S,Nm,Nc,Nm,Nc,0,0,Path) 

Nm  >=  Nc,  ppl  ([[  S,Nm,Nc,  0,0  ]|  Path  ])  . 

misCan  (S,Nm,Nc, Ml, Cl, Mr, Cr, Path) 
safe  (Nm,Nc,  Ml, Cl, Mr, Cr)  , 
equal  ([S,Ml,Cl,Mr,Cr  ],P), 
not  (member  (P  ,Path) )  , 

SI  is  -S, 

possible  (S,M1,C1, Mr  , Cr  ,  Ml  1,  Cl  1,Mr  1,  Cr  1)  , 
misCan  (S 1  ,Nm  ,Nc,Ml1  ,C1 1  ,Mr  1 ,  Cr  1 ,  [  P  |  Path  ])  . 

saf e  (Nm,Nc,Ml,Cl,Mr,Cr) 

Ml  >=  0,  Ml  =<  Nm, 

Cl  >=  0,  Cl  =<  Nc, 

(Ml  >=  Cl  ;  Ml  =:=  0)  , 

(Mr  >=  Cr  ;  Mr  =:=  0)  . 

possible  (S,Ml,Cl,Mr,Cr,Ml1,Cl1,  Mr  1,Cr  1) 

(Mil  is  Ml-2 *S, 

Mrl  is  Mr  +  2*S, 

C11  is  Cl, 

Crl  is  Cr) ; 

(Mil  is  Ml, 

Mrl  is  Mr, 

Cll  is  Cl- 2 *S, 

Crl  is  Cr  +  2*S)  ; 
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(Mil  is  Ml— S , 

Mrl  is  Mr+S, 

C11  is  Cl-S, 

Cr 1  is  Cr  +  S)  ; 

(Mil  is  Ml— S  , 

Mrl  is  Mr+S, 

Cll  is  Cl, 

Crl  is  Cr)  ; 

(Mil  is  Ml, 

Mrl  is  Mr, 

Cll  is  Cl-S, 

Crl  is  Cr  +  S)  . 

member  (X,[  ])  :-  I, fail. 

member  (X,[  X  |  L])  . 

member  (X,[  Y|  L])  :-  member(X,L). 

equal  (X,  X)  . 

PPL  ([  ])  . 

PPL  (l  X|  L  3)  :-  print  (X),  nl,  ppl  (L) 
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APPENDIX  E 

OMEGA  APPLICATION  EXAMPLES 

t********************************************************** 

I  Monte  Carlo  Simulation  for  3  node  message  network. 

********** ****** ************************** ********  ********* 

I  the  relations 

define{root,  "Begin",  newrel  {}}  . 
define  {root,  "End",  newrel  {}}. 
define  {root,  "Clock",  newrel  {}}  . 
define{root,  "NextTime",  newrel  £} }  . 
define{root,  "LastTime",  newrel  J}}* 
define  {root ,  "Event",  newrel  {}}. 
define{root,  "ProcessE  vents  ",  newrel  {}}. 
define  {root,  "ProcessEventsAux" ,  newrel  {}}  . 
define  {root,  "Summary",  newrel  {}}  . 
define{root,  "Status",  newrel  03- 
define{root,  "BusyTime",  newrel  {}}  . 
define{root,  "QLength",  newrel  {}}  . 
define  {root,  "Stats",  newrel  {}}  . 
define  {root,  "BusyStats",  newrelQ}  . 
define{root,  "QStats",  newrel  {}}. 
define{root,  "Totals",  newrel  {}}. 
define  {root,  "NodeTotals",  newrel  {}}. 
define{root,  "JobTotals",  newrel{}} . 
define{root,  " JobTotalsAux",  newrel  {}}. 
define{root,  "DisplayLine",  newrel  {}}. 
define{root,  "Start",  newrel  {}}. 
define{root,  "Arrive",  newrel£}}. 
define{root,  " Ne wArrival" ,  newrel  {}}. 


186 


I 


define {root,  "Service",  nevrel  {}} . 
define  {root,  "StartTime",  newrel{}}. 
define{root,  "Depart",  newrel  {}}. 
define  {root,  "EzitTime",  newrel 0 } . 
define{root,  "InService",  newrel{}}. 
define{root,  "Q",  newrel  {}}. 
define  {root,  "Eng",  newrel  {}}  . 
define{root,  "CalcNextArr ",  newrel  {}  ] . 
define{root,  " CalcDepar ture" ,  newrel  {}}. 
define  {root,  "CalcHoute",  newrel  {} }  . 
define{root,  "NewJob",  newrel  {}}. 
define  {root,  " JobSer viceT",  newrel{}}. 
define{root,  "JobCount",  newrel Q). 
define{root,  "GenArrT",  newrel  {]}  . 
define  {root,  "GenServT",  newrel 0}. 
define  {root,  "GenBoute",  newrel  {}}. 
define  {root,  "Servicelime",  newrelQ). 
define  {root,  " Arrlnterval",  newrel  {}}. 
define  {root,  "PossibleRoutes",  newrel  {}}  . 
define{root,  "Seed",  newrel{}}. 
define{root,  "Rnd",  newrel  {}}  . 
define{root,  "RndList",  newrel  {}} . 
define{root,  "WorkList",  newrel  {}}  • 

!  the  Nodes 

define  {root,  "Nodel",  newob  j  {}}  . 
define  {root,  "Node2",  newob  j  {}}  . 
define{root,  "Node3",  newobjQ}. 
define  {root,  "Out",  newobjQ}. 

!  initalize  MonteCarlo  tables 

!  Service  times  (message  transmission  times) 

Servicelime  (1 ,  0,  12). 
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ServiceTime  (2,  13, 

32) 

• 

Ser viceTime  {3,  33, 

7  9) 

• 

ServiceTime  (4 ,  80, 

9  2) 

• 

Serv iceTime  (5,  93, 

99) 

• 

!  Interarriva 

.  1  times 

Arrlnterval  (Node  1, 

1, 

0, 

16). 

Arrlnterval  (Nodel, 

2, 

17, 

24)  . 

Arrlnterval  (Nodel, 

3, 

25, 

49)  . 

Arrlnterval  (Nodel, 

4, 

50, 

91)  . 

Arrlnterval  (Nodel, 

5, 

92, 

99)  . 

Arrlnterval (Node2, 

1, 

0, 

28)  . 

Arrlnterval  (Node2, 

2, 

29, 

70)  . 

Arrlnterval  (Node2, 

3, 

71, 

85)  . 

Arrlnterval (Node2, 

4, 

03 

<y\ 

92)  . 

Arrlnterval  (Node2, 

5, 

93, 

99)  . 

Routing  table 


PossibleRoutes. (Nodel  , 

Node2 , 

0, 

29) 

PossibleRoutes (Nodel , 

Node3 , 

30, 

59) 

PossibleRoutes (Nodel , 

Out, 

ON 

o 

* 

99) 

PossibleRoutes (Node2 , 

Nodel , 

o. 

29) 

PossibleRoutes (Node2, 

Node3 , 

30, 

49) 

PossibleRoutes (Node2, 

Out , 

50, 

99) 

PossibleRoutes (Node3 , 

Out, 

o. 

99) 

I  Random  number  table 

RndList  ([ 

97,9  5, 12,1  1, 90,  4  9, 57, 13,8  6,  81, 
02,92,75,91,24,58,39,22, 13,02, 
80,67, 14,99, 16,89,96,63,00,04, 
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96/76,20,28,72, 12,77  ,23 ,79,46, 
55,  6  4,82,61,73,  94,26, 18,3  7,  3  1, 
50,02,74,70,16,85,95,32,85,67, 
29, 53,08,33, 81, 34, 30,21,24, 25, 
58,  16,01,91,70,0  7,50,13, 18,2  4, 
51,  16,69,67,  16, 5  3,  1  1 ,06,36,  10, 
04,55,36,97,30,99,80,10,52,40, 

86. 54.35.61.59,  89,64,97, 16,02, 
24,23,52,11 ,59, 10, 88,68, 17,39, 
39,36,99,50,74, 27,69,48,32, 68, 
60,71  ,41  ,25,90,93,07  ,24,29,5  9, 
65,88,48,0  6,68,  92,7  0,97,02,6  6, 
44, 74, 1  1  , 60, 14, 57, 08, 54, 12,  90, 
93, 10, 9 5; 80, 32, 5 0,4 0,44 ,08, 12, 
20,46,36,19,47,78, 16 ,90,59,64, 
86,54,24,88,94, 14, 58,49, 80,79, 
12,88,12,25,19,70,40,06,40,31, 
42,  00,50,24,  60, 90,69 ,60,0  7,86, 
29, 98, 81  , 63, 61, 24, 90, 92, 32, 68, 
36,63,02,37,89, 40, 81 ,77,74,82, 
01,77,82,78,20,72,35,38,56,89, 

41.6  9,43,37,41,21,36  ,3  9,57,80, 
54,40,76,04,05,01,45,84,55, 11, 
68,0  3,8  2,3  2,22,  8  0,  92,47,77,6  2, 
21,3  1  ,77,75,43,  13,83,43,70,  16, 
53,64,54,21,04, 23,85,44,81,36, 

91. 66. 21. 4 7. 95. 69. 58. 91. 47. 59, 

48.7  2,74,4  0,97,  92,  05,01,61,  18, 
36,21 ,47,71,84,46,09,85,32,82, 
55,  9  5,24,8  5,  84,5  1,6  1  ,60,62,  13, 
70,2  7,01 ,88,84 ,85,77  ,94,67,35, 
38, 13,66, 15,38, 54, 43,64,25,43, 
36,80,25,24,92,98,35,12,17,62, 
98,  10,9  1,61,04,  90,  05,22,75,  20, 
50,54,29,19,26,26,87,94,27,73 
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])  - 


1 


WorkList  (Nil)  . 

!  Intialize  Queues 

C  (Nodel  ,  Nil)  . 

Q  (Node2,  Nil)  . 

Q  (Node3  ,  Nil). 


!  the  Precedence  function 

!  Scheme  is  (for  events  5)time  =  t,  node=n) 

!  Departures  have  top  priority 

!  Between  occurrences  of  same  type  of  event 

l  JobN  1  precedes  JobN2  if  N1  <  N2. 

!  This  function  replaces  a  sort  on  the  event  list. 

fn  ?recedence[e1,  jl,  e2,  j2]  : 

if  e1=e2  8  j  1<j2  ->  "TRUE" 

else  if  e1  =  Depart  8  e2  -»=  Depart  ->  "TRUE" 
else  Nil. 


!  The  Rules  -  /. 

define  (root,  "SimRules", 

« 

!  Begin  —  Begins  the  simulation  and  sets  up  relations 

j 

if  *Begin(a,  n)  ->  (  ;• 

JobCount(0,  0,  n)  ; 

LastTime  (0)  ;  .  •] 

- 

.  1 
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In  Service  (No  del , 

; 

InService (Node2, 

"--")  ; 

InService  (Node3 , 

" — ")  ; 

BusyTime  (Node), 

0) ; 

BusyTime  (Node2, 

0)  ; 

BusyTime  (Node3, 

0) ; 

QLength  (Nodel, 

0)  ; 

QLength  (Node2, 

0)  ; 

QLength  (Node3, 

0) ; 

Event (0,  Start, 

II - If  It 

$ 

Clock  (0)  ; 

a  ("OK")  ; 

} ; 

j 

!  End  —  cleanup  for  further  runs 

j 

if  *End  (a)  ->  { 

pur ge  [ JobCount}  ; 
purge  (InService}  ; 
a  (End)  ; 

} ; 

i 

!  the  clock  rules  --  drives  the  simulation 

i 

if  *Clock(999),  *LastTime  (t)  ->  { 

Totals  {t} ; 

End  (}  ; 

} 


else  if  *Clock(t2),  ^lastTime  (t  1)  ->  { 


Sta ts { 1 1  ,  t2 } ; 
displavn { 

» - "}  ; 

display {"Time  :  "}  ; 
displa  yn  {t2}  ; 
displayn  {"Events  :"}  ; 

ProcessE  vents  {t2}  ; 

Summary  {}  ; 

LastTime  (t 2 )  ; 

Clock (NextTime {999} )  ;  i  restart  the  clock 

} ; 

if  *NextTime(a,  tl)  ,  £¥601(12,  e,  n,  j)  ,  t2  <  tl  -> 
NextTime  (a,  t2) 

else  if  *NextTime(a,  t)  -> 
a  (t)  ; 

; 

!  Process  all  events  for  time  t 

j 

if  *ProcessEvents (a ,  t)  ,  Event  (t,  el,  nl,  j  1 )  ->  { 

ProcessEventsAux {t,  el,  nl,  jl}; 

ProcessEvents  (a,  t)  ; 

} 

else  if  *ProcessEven ts (a,  t)  -> 
a  (t)  ; 

if  *ProcessEventsAux  (a,  t,  el,  nl,  pi). 

Event  (t,  e2,  n2,  j2)  , 

Pr ecedence{  e2 ,  j2,  el,  jl]  -> 

ProcessE ventsAux (a,  t,  e2 ,  n2,  j2) 

else  if  *ProcessEventsAux (a,  t,  e,  node,  job)  ->  { 

-’Event  (t,  e,  node,  job)  ; 
e  {t ,  node,  j ct}  ; 
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END 


display £"  "}  ; 

displayn  £e,  node,  job}; 
a(t); 

}; 


!  Summarize  the  current  status  for  all  nodes 

» 

if  *Summary  (a)  ->  £ 

Status  {Node  1}  ,  Status  £Ncde2}  ,  Status  £Node3}  ; 
displayn  {}  ; 

displayn  {"Pending  Events  i"}  ; 

Pp  {Event} ; 
displayn  {}  ; 
a(»»)  ; 

}; 


if  *Status(a,  node),  InService  { rode,  job),  Q(node,  1)  -> 

£ 

displayn  {node}  ; 

display £"  Job  in  service  :  "} ; 

displayn  {job}  ; 

display £"  Jobs  in  gueue  :  "} ; 

if  l=Nil  ->  displayn £"--"} 
else  displayn  £1}; 
a (node)  ; 

} ; 

j 

!  Keep  running  totals  for  stats  on  each  node. 

I  The  relations  are  : 

BusyTime  (node,  t)  --  Cumulative  idle  time 
QLength  (node,  n)  --  Time  weighted  Q  length 


! 


if  *Stats(a,  tl,  t2)  ->  £ 

BusyStats £t  1 ,  t2,  Nodel}; 

BusyStats £t 1  ,  t2,  Node2}; 

BusyStats £t  1 ,  t2,  Node3}; 

QStats£t1,  t2,  Nodel}; 

QStats  £t1,  t2,  Node2}; 

QStats£t1,  t2,  Node3}  ; 

a (t 1)  ; 

}; 

if  *BusyStats (a,  tl,  t2,  node),  InService  (node,  '•--")  -> 
a  (node) 

else  if  *BusyStats (a,  tl,  t2,  node),  *BusyTime (node,  t)  -> 
BusyTime(node,  t+t2-t1)  , 
a (node)  ; 

if  *QStats  (a ,  tl,  t2,  node),  *QIength  (node,n) ,  Q  (node,l)  -> 
QLength (node,  n  ♦  ( t2-t  1)  *length[  1  ])  , 
a  (node)  ; 

i 

* 

!  Totals  —  Display  stat  summary  at  end  of  simulation 

t 

if  *Totals (a,  t)  ->  { 

display  {"  Total  time  :  ; 

displayn  £t}  ; 
displays  {}  ; 

OisplayLine  {["Node",  ’’Busy",  "QLen"]}; 

Displa  yLine  {£  " - "  ]}  ; 

NodeTotals  {Nodel} ; 

NodeTota  Is  £N  cde2}  ; 


NodeTotals £Node3} ; 
displayn  {}  ; 

DisplayLine ££  "Job",  '•Tine"]}  ; 

DisplayLine  [£  M - "  ]}  ; 

JobTotals {Nil,  0}  ; 
a{t)  ; 

); 

if  *NodeTotals  (a  ,  node),  *BusyTime (node ,  t)  , 

♦  QLength  (node ,  n)  ->  { 

DisplayLine  ££node#  t,  n  £}  ; 
a (node)  ; 

}; 

if  *JobTotals (a,  1,  n) , 

♦  StartTime  ( j ,  tl)  ,  *ExitTime(j,  t2)  -> 

JobTotals  (a,  cons£[j#  t2-t1  ],  1],  n+t2-t1) 

else  if  *  JobTotals  (a ,  1,  n)  ->  { 

JobTotalsAux  {1}  ; 
displayn  £}  ; 

DisplayLine  ££  "Total" ,  n  ])  ; 
a  (JobTotals)  ; 

}; 

if  *JotTotalsAux  (a.  Nil)  -> 
a  (JobTotalsAux) 

else  if  *JobTo  talsAux  (a,  1)  ->  ( 

DisplayLine  £f irst£  1  ]} ; 

JobTotalsAux  (a,  rest£l]); 

} ; 


if  *DisplayLine  (a.  Nil)  ->  £ 
displayn  £}  ; 
a  (Displa yLine)  ; 


else  if  *DisplayLine  (a#  1}  ->  £ 
display £”  "} ; 

display  £first£l  ]}  ; 

DisplayLine  (a#  restfl])  ; 

}; 

t 

!  the  events  --  Start#  Arrive#  Depart 

t 

if  *Start(a#  t#  x#  y)  ->  £ 

CalcNext Arr  £t#  Nodel}; 

CalcNext Arr £t,  Node2} ; 
a(t)  ; 

}; 

if  *Arrive  (a#  t#  node#  "NewJob")  ->  £ 
NevArrival £t #  node,  NewJob  £}}; 
a(t) 

} 

else  if  *Arrive (a,  t.  Out,  job)  ->  £ 
ExitTime  (job  ,  t)  ; 
a(t) 

) 

else  if  *Arrive(a,  t#  node#  job)  ->  £ 
Service £t,  node#  job}; 
a(t)  ; 

}  ; 

if  *NevArrival (a#  t#  node#  job)  ->  £ 
StartTime ( job,  t)  ; 

CalcNextArr £t,  node}; 

JobServiceT  (job,  GenServT  £Rnd  £} } )  ; 
Service £t#  node,  job}; 


if  *Service(a,  t,  node,  job),  *InService  (node,  " — ••)  ->  { 
InService  (node,  job); 

CalcDeparture  {t,  node,  job}  ; 
a  (t) 

} 

else  if  *Service  (a,  t,  node,  jot)  ->  { 

Eng  {node,  job}; 
a  (t)  ; 

}; 

if  *Depart(a,  t,  node,  job), 

Q  (node.  Nil),  *InService (node,  job)  -> 

InService  (node,  " — '•), 
a  (t) 

else  if  *De part  (a,  t,  node,  job), 

*Q  (node ,  1),  *lnService  (node,  job)  -> 

{ 

Q(node,  rest£l])  ; 

InService (node,  " — ") ; 

Service  {t,  node,  first[l]}; 
a  (t)  ; 

} ; 

if  *CalcNextArr (a, t , node)  ,  JobCcunt  (n1,n2,  max)  ,  n1>  =  max  - 
a(t) 

else  if  *CalcNextArr  (a, t,node) ,  *JobCount  (nl ,n2, max)  -> 

{ 

JobCount  (n1+  1,  n2,  max); 

Event  (t  +  GenArrT  {node, End  {}  }  ,  Arrive,  node,  ,,NevJobM) 


}; 


if  *CaicDeparture (a, t,node, job)  ,  JobServiceT  (job ,servT)  -> 

( 

Event (t+servT, Depart , node,  job)  ; 

Event  ( t+ser vT, Arrive  ,GenEoute  [node.  End  {}  }  ,  job)  ; 
a(t); 

}; 


if  *Eng(a,  node,  job),  *Q(node,  1)  -> 

Q  (node,  append£l,  [job];), 
a  (node)  ; 

if  *NewJob(a),  *  JobCount  (nl,  n2,  max)  -> 
JobCount(n1,  n2  +  1,  max), 
a  ("Job"  +  in  t_str[n2*  1  ])  ; 


1  parameter  generators 

1  GenServT  —  Generate  a  service  time  for  a  message 

I  GenArrT  —  Generate  an  interarrival  time  for  a  job 

!  GenEoute  —  Generate  the  next  node  for  a  departure 

I 

if  *GenServT(a,  x)  ,  ServiceTime  (t,  il,  i2)  , 

(x  >=  il)  6  (x  <=  i2)  -> 
a  (t)  ; 

if  *GenArrT  (a,  node,  x)  ,  Arr Interval  (node,  t,  il,  i2)  , 

(x  >=  il)  &  (x  <=  i2)  -> 
a(t)  ; 


1 S  8 


if  *GenRoute{a,  node,  x)  ,  PossibleRoutes  (node,  n2,  il,  i2) 
(x  >=  il)  &  (x  <=  i2)  -> 
a{n2) ; 

i 

!  The  random  number  generator  .... 

!  The  Rnd  procedure  takes  the  first  number  from  the 

I  list  of  random  numbers  in  WorkList. 

!  Seed  makes  the  WorkList  the  portion  of  the 

!  RndList  with  the  ith  member  as  the  first  member. 

!  If  the  list  of  random  numbers  is  exhausted, 

I  the  WorkList  is  set  back  to  the  beginning  of 

!  the  original  list  of  random  numbers. 


if  *Seed(a,  n)  ,  RndList  (1)  ,  *WoikList  (wl)  -> 
WorkList  (ith[l,  n]), 
a  (n)  ; 

if  *Rnd  (a)  ,  *WorkLis t  (Nil)  ,  RndList  (1)  -> 
WorkList  (re  st[l])  , 
a(first[  1]) 

else  if  *Rnd(a) ,  *WorkList(l)  -> 

WorkList  (rest[l ])  , 
a  (first[  1  ])  i 

»}. 

!  Activate  the  rules... 


activate  {SimRules} . 


2  **********************  ************************ 
!  ! 

!  Towers  of  Hanoi  ! 

!  ! 

t  ***  ******************************************* 

!  define  the  relations 

define  [root,  "Hanoi",  newrelQ}. 
define  {root,  "HanoiAux",  newrelQ). 

!  The  rules 

define  {root,  "HanoiB ules", 

« 

if  *Hanoi(a,  n)  -> 

Hanoi Aux  (a,  n,  "A",  "C",  "B")  ; 

if  *HanoiAux(a,  1,  from,  to,  aux)  ->  { 

display  {"Move  disk  1  from  peg  "}  ; 
display {from}  ; 
display {"  to  peg  ; 
displayn  {to}  ; 
a  ("") 

} 

else  if  *HanoiAux(a,  n,  from,  tc,  aux)  ->  { 
HanoiAux  {n- 1 ,  from,  aux,  to}; 
display  {"Move  disk  "}  ; 
display  {n}  ; 

display{"  from  peg  ; 
display {from} ; 
display  {"  to  peg  ; 
displayn  {to}  ; 

HanoiAux  {n- 1 ,  aux,  to,  from}; 
a  ("  ")  ; 

) 

»  )• 
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activate  {Hanoifiules}  . 

displayn  {"Towers  of  Hanoi  :  Osage  :  Hanoi  {n}"}. 

i *** **********************************************  ***** ** 

I  The  Sieve  of  Eratosthenes  ! 

!  ! 
!For  a  description  of  this  algorithm,  see  ! 

! 'Eratosthenes  revisited  :  Once  More  through  the  Sieve',! 
!by  Jim  and  Gary  Gilbreath,  Byte,  Jan  83,  p  283.  ! 

i  t 

t  ******************************  ***********  ********* *****1 

define  {root,  "Sieve",  newrelj}}. 
define{root,  "SieveAux",  newrelG). 
define{root,  "Iota",  newrel{}}. 
define{root,  "PurgeMultiples",  newrelQ}. 

!  the  rules 

define  {root,  "SieveEules", 

« 

if  *Sieve(a,  n)  ->  system  ("date")  , 

SieveAux(a,  0,  n-1,  lota{0,  n-1,  newrel{}}); 

if  *Iota(a,  nl,  n2,  r),  nl  >  n2  -> 
a  (r) 

else  if  *Iota(a,  nl,  n2,  r)  -> 
r(n2), 

Iota(a,  nl,  n2-1,  r)  ; 

if  *SieveAux(a,  nl,  n2,  r) ,  nl  >  n2  -> 
a ("OK") 

else  if  *SieveAux(a,  nl,  n2,  r)  ,  r  (nl)  ->  { 


display  £"Pri me  :  "}  ; 
displayn  £2*n  1  +  3}; 

PurgeM ultiples £2*n1  +  3,  3*n1  +  3,  n2,  r} ; 
SieveAux(a,  n  1+1,  n2,  r); 

} 

else  if  *SieveAux(a,  nl,  n2,  r)  -> 

SieveAux  (a,  nl+1,  n2 ,  r); 

if  *PurgeM ultiples  (a ,  prime,  sun,  n,  r)  ,  sum  >  n  -> 
a(r) 

else  if  *PurgeMultiples  (a,  prime,  sum,  n,  r)  ,  *r  (sum)  -> 
PurgeM ultiples (a,  prime,  prime+sum,  n,  r) 

else  if  *PurgeMultiples (a,  prime,  sum,  n,  r)  -> 

PurgeM ultiples (a,  prime,  prime+sum,  n,  r)  ; 

»  }• 

activate {SieveRules}  . 

displayn  {"The  sieve  is  loaded  :  Osage  :  Sieve  [nj  . 

i ********** ************** ******  **************************** 
!  ! 

!  Rules  and  associated  definitions  for  a  universal  ! 

!  interpreter/pretty  printer  for  a  small  language  of! 

!  arithmetic  expressions.  ! 

!  ! 

J  *** ***************************  ************************ ***  t 

!  definitions 

define{root,  "Small",  newrel  £}}  ; 
define£root,  "Wait",  newrelQ); 
definefroot,  "Eval",  newrelQ}; 
definefroot,  "Value",  newrel  {}}; 


define  (root , 
define  {root, 
define  {root, 
define  {root, 
define  {root, 
define  {root, 
define {root, 
define {root. 


"Appl",  newrel{]}; 
"Op",  newrel  {} }  ; 
"Left",  nevrel{}}; 
'•Eight”,  newrelQ}; 
"Con",  newrel  {}}; 
"Litval”,  newrel  {}}; 
"Meaning”,  newrel  {}}  ; 
"Template”,  newrel 0} 


!  seme 

objects 

define {root. 

"  N 1  ” , 

newob  j 

0}  ; 

define {root. 

"  N  2  "  , 

newob j 

0); 

define  {root. 

"  N  3  "  , 

newob  j 

0} ; 

define  {root. 

»N4  ", 

newob  j 

0}  ; 

define  {root. 

"  N  5  "  , 

newob j 

{}}. 

I  functions 

fn  Id[x]  :  x; 

fn  Sum£x,y]  :  x  +  y; 

fn  Product£x,y]  :  x  *  y; 

fn  upSum£x,y]  :  "("  +  x  +  "  +  "  + 

fn  upProd£x,y]  :'»(«+  x  +  '•  x  "  + 


I  initialize  the  database 

Appl  { N 1 )  ; 

Cp  ("x",  N1 )  ; 

Left  ( N  2,  N 1)  ; 

Eight  (K3,  N1)  ; 

Appl  (M2)  ; 

Op("+",  M2)  ; 

Left  (N4,  N2) ; 

Right  (N5,  N2) ; 

Con  (N3)  ; 


2 


litval  (6  ,N3)  ; 

Con  (N4)  ; 
litval  (3,N4)  ; 

Con  ( N 5 )  ; 

Litval  (5/N5)  ; 

Meaning  (Sum,  "  +  ")  ; 

Meaning  (Product,  "x" )  ; 

Meaning(Id,  ,,lit")  ; 

Template  (upSum,  "+")  ; 

Template  (upProd,  "x"); 

Template  (int_str,  "lit")  ; 

!  the  Rules 

define  (root,  "SmallR ules" , 

« 

!  Driver  rule 
if  *Small(node) 

-> 

Eval  (Meaning ,  node), 
Eval  (Template,  code) 
Wait  (node)  ; 

if  *Value  (Meaning,  x,  node), 
♦Value (Template,  y,  node) 
♦Wait  (node) 

-> 

displayn  (x)  , 
displayn  (y)  ; 

!  Inheritance  rules 

!  Leaf  node 
if 

♦Eval  (class ,  e)  , 


i 

S'. 

A 


Con  (e)  , 
litval  (v,e)  , 
class (f,  "lit”) 

-> 

Value(class,  £[  v],  e)  ; 

!  Appl  node 
if 

♦Eval  (class#  e)  , 

Appl  £e)  , 

left(x,e),  Right  (y,e) 

-> 

Eval  (class,  x)  , 

Eval  (class,  y)  ; 

!  Synthesis  rule 

if 

♦Value  (class ,  u,x)  , 

♦Value  (class,  v,y), 

Appl(e), 

Op  (n,e)  , 
left  (x,e)  , 

Right  (y,  e)  , 
class (f,  n) 

-> 

Value(class,  f£u,v],  e) 

»  }• 

!  activate  the  rules 


activate  {  SmallRules  }. 

displayn  {"Small  interpreter  loaded  ;  u  Small(NI)"} 
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